Open agracey opened 2 years ago
Thanks for raising this issue @agracey. I imagine the pathway to implementation will involve a fair bit of discussion and perhaps an RFC, but this is a great place to get started. I'll flag this for discussion in our next team sync (details if interested).
From our conversation this morning.
It might be more interesting to allow buildpack authors to specify artifacts to package and publish in a more general way. For example, this could allow you to build a helm chart along with your container and have them both be published to and OCI registry.
I'll read through the recently approved RFCs to see if they could be used to adapted to solve this use case then bring it up on slack and write an RFC if they don't.
Changed name to be a broader feature request
Description
Edit: During a conversation in one of the weekly meetings, we were thinking that this could be expanded with minimal additional engineering effort to include any OCI artifact and not just WASM.
I'd like to be able to build wasm applications using cloud native buildpacks. There is an increasing demand for wasm workloads due to how fast and small they can be as well as how much more secure the sandbox is than a standard container. Building the capabilities into the lifecycle component would allow downstream platforms to leverage wasm with less work.
Proposed solution
While I only have a superficial understanding of the internal mechanisms, I believe this can be enabled with a few non-disruptive changes.
Describe alternatives you've considered
It's also possible to build wasm in a basic container but then you don't get all the benefits of buildpacks and it's ecosystem.
Additional context
Actually using this feature would be up to the buildpack authors. I would not expect current buildpacks to use this feature seamlessly. The buildpacks themselves would also need to be wasm runtime aware.