cli icon indicating copy to clipboard operation
cli copied to clipboard

feat: Add Jsonnet support for matrix based building

Open gmpinder opened this issue 3 months ago • 17 comments

So there was some conversation in discord and some in a discussion about trying to have support for a recipe building multiple versions of itself. For example @qoijjj has mentioned that it would be much easier to support the transition of SecureBlue to Fedora 40 if all that needed to be done was to mark each recipe to build both a 39 version and a 40 version.

My proposal is to allow the existing image-version property in the top level to accept both a single value and an array of values. This would allow existing recipes to continue working and allow scaling up builds. So an example recipe could look something like this:

name: cli/test
description: This is my personal OS image.
base-image: ghcr.io/ublue-os/silverblue-surface
image-version:
  - 40
  - 39
modules:
  - from-file: akmods.yml

The CLI would then go through and build 2 separate images, one based on 39 and one on 40. All tags that are currently created contain the version of Fedora that built except latest. In this instance, we would set latest to the highest version that is being built. This could also open the door to supporting a gts tag for the second highest version.

Now there is a possibility that there will be recipe's that have module definitions that make it incompatible across versions. At this point, it would be up to the user to separate out the recipes and manage these changes. Or we can support having a for-version or some property for each module that makes it so that you can cordon certain modules to only be ran on a specific version. Like:

modules:
  - type: rpm-ostree
    for-version: 40
    install:
      - binutils

gmpinder avatar Mar 26 '24 18:03 gmpinder