buildpacks / samples

Samples for Cloud Native Buildpacks
Apache License 2.0
193 stars 145 forks source link

Provide MultiArch buildpack samples #187

Open WYGIN opened 3 months ago

WYGIN commented 3 months ago
WYGIN commented 3 months ago

Not sure about the folder structure of the multi-arch samples I am thinking of

multi-arch
├── extensions/
|   └── [...]
├── builders/
|   └── [...]
└── buildpacks/
    └── hello-world/
        ├── buildpack.toml
        ├── package.toml
        ├── linux/
        |   ├── arm64/
        |   └── amd64/
        └── windows/

or

/
├── buildpacks
|   ├── hello-world/
|   |   └── [...]
|   └── multi-arch/
|        └── hello-world/
|            ├── buildpack.toml
|            ├── package.toml
|            ├── linux/
|            |   ├── arm64/
|            |   └── amd64/
|            └── windows/
├── builders/
|   └── [...]
└── extension/
    └── [...]

which one do you prefer? and any ideas on different approach?

cc: @jericop @jjbustamante @natalieparellano

jjbustamante commented 3 months ago

Well, the demo I showed during Kubecon EU 24 is here I did the following:

The samples buildpacks are just bash scripts, it could be even simpler just updating the buildpack.toml and package.toml with Targets or if we want to demonstrate something else, we can also duplicate the binaries (as I did it in the demo) and maybe add some logging but I do not see a lot of value there.

From your folder structure, I think I prefer the first one, where we don't use multi-arch in the folder structure.

Maybe we can start having a draft PR with those changes and wait till the RFC is merged and the implementation is ready to merge it in

AidanDelaney commented 3 months ago

Thanks a lot for pushing this work forward @WYGIN. We really appreciate it.

I think I'd like all of our samples to be multi-arch by default. Then treat the non multi-arch as the exception. Like, @jjbustamante I'd love to see this work on a branch so that we can merge it when the RFC lands.