Open WYGIN opened 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
Well, the demo I showed during Kubecon EU 24 is here I did the following:
hello-world
, hello-moon
, hello-universe
buildpacks an a multi-arch jammy
builder.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
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.