Derived configurations

[kaniini]

Writing apko YAML files can be very repetitive. It would be desirable to be able to have a base configuration that can be inherited from.

Something like:

from: github.com/chainguard-dev/apko/baseimages/alpine-edge.yaml@main

contents:
  packages:
    - nano
    - build-base
    - openssl-dev

I think from should imply a git repository, given the GitOps tooling built around distroless, and kind of feel like go package system. At least, it makes sense to me.

The settings in the config file would be overlaid on top of the base config.

[mattmoor]

Generally 👍 from me. I like the idea of source-level dependencies for these, certainly by default.

I think we could simplify a number of the distroless images using this, especially around the existence of a nonroot user, and things like ca-certificates and the base data stuff. Definitely more composable, which I'm a fan of.

I think an interesting thing to consider here is: to layer or not to layer?

Folks will almost certainly assume that these end up layering, but I could understand why they might not.

[imjasonh]

+1 to making these composable. Would from: also accept a local file path?

My only worry about the word from is that it might make folks think it controls the image's base image, which it kind of does, if the result is separate layers.

Not that this means we shouldn't call it from, just that docs should be extra clear how it differs from FROM. 😅

[kaniini]

I mean we can play around with the keyword used for this. I just want to make sure we get the design right because if we release a botched design, there’s going to be a challenge fixing it.

[amouat]

Definitely +1 from me.

Just to be clear, this is effectively combining the 2 yaml files? All the config including entrypoint etc will copied in?

It might be worth having an option that spits out the resultant yaml for debugging.

You could call the option "include", but that may imply a literal and complete copy being inserted. That makes me wonder if we can do that at the minute i.e. if I specify entrypoint twice, will/should the second one override it? What about packages - does that combine the two rather than override?

[mattmoor]

+1 to emitting the rendered version for debugging, that sounds very helpful.

Ironically this is what made debugging #include palatable in my C++ compiler days, and I was always unhappy I couldn't get a similar thing from templates 🙃

[kaniini]

Moving this to v0.5 because too many unanswered questions about how the inheritance will work. Needs time to ruminate when it lands.

[kaniini]

This was done in v0.5 but apparently I forgot to close the issue.