Limitations of our system

[xynydev]

...and how to tackle them?

I can think of one:

• Building two versions, say 38 and 39, of your image is hard.
  • Have to create two recipes and use a shared module file, so three files.
  • You ideally want the images to have the same name, right? latest wont be the latest version anymore, rather the image whose build completed later. The only way to solve this is two differently named images, which isn't nice.
  • Discussion continues at: feat: Add Jsonnet support for matrix based building cli#140

[gmpinder]

So we could support supplying an array into the version key in the recipe. Honestly wouldn't be too hard to add.

[xynydev]

Yeah, thought so too. Morning walk revelations. I'm just unsure, like, wouldn't the template command have to have two outputs then?

[gmpinder]

Yeah you're right, didn't think about that. Something to noodle on

[gerblesh]

I was thinking we could do something like this in a recipe.yml file:

# image will be published to ghcr.io/<user>/<name>
name: template
# description will be included in the image's metadata
description: This is my personal OS image.

# the base image to build on top of (FROM) and the version tag to use
base-image: ghcr.io/ublue-os/silverblue-main
image-version: 39 # latest is also supported if you want new updates ASAP

image-tags:
    - latest
    - 39

keeping the recipe.yml files seperate makes sense because packages can be different between them, behavior, versioning, etc

# image will be published to ghcr.io/<user>/<name>
name: template
# description will be included in the image's metadata
description: This is my personal OS image.

# the base image to build on top of (FROM) and the version tag to use
base-image: ghcr.io/ublue-os/silverblue-main
image-version: 39 # latest is also supported if you want new updates ASAP

image-tags:
    - gts
    - 38

[xynydev]

I think having mutiimage support should live inside our root recipe.yml

Gerblesh's idea is not that, though, right?

[bayou-brogrammer]

Apologies, multi-tagging

[xynydev]

This highlighted issue actually is a pretty strong paraller to the other one. This seems to be a major structural problem to solve, so it's best to brainstorm so we can do it well.

I don't think the version tag should be declared with the image tags, that should come from the image. And the latest tag (and pr and branch tags, etc.) should be default, if the array isn't declared.

I'm not sure about making multiple recipes that build the same exact image, though... At the same time, there would be package differences, so maybe this is just an inevitability.

This might also be a good time to think more about the batch building aspects. Something like secureblue with it's huge folders of recipes seems inefficient from the outside, but it's also well defined and structure. Going to have to hear @qoijjj about that.

[RoyalOughtness]

secureblue has large folders of recipes because we have almost 100 recipes. The existing structure is highly efficient because it permits us to factor out and reuse large chunks of yaml dozens of times. So I'm confused on multiple fronts 😄 One is what inefficiency you're referring to, and two how the recipe structure relates to this thread.

[xynydev]

Glad you don't find it inefficient. I was just saying that a lot of those recipes use the same modules or have a change depending on some parameter. Ublue would probably have used a multi-item build matrix to sculpt out that, and a system similar to packages.json. Such a system could be considered more efficient.

[gerblesh]

I'm not sure about making multiple recipes that build the same exact image, though... At the same time, there would be package differences, so maybe this is just an inevitability.

Building from Fedora 38 vs building from Fedora 39, or Rawhide, are fundamentally different images, if things can be shared between the images, you use from-file. This isn't perfect, but trying to build multiple different images from a single recipe.yml can make debugging a pain and often with package changes and versioning changes, the recipe.ymls will need to be seperated anyways.

It would be nice to auto-tag the fedora version and latest, or gts if tags aren't specified, however for larger projects it would be more useful to be able to more directly control image tagging, so when the option is provided in yaml, they override all auto-generated tags

[xynydev]

gts couldn't be auto-generated, because the minus-one of the latest Fedora version might be the latest version for the image being built, so doing that would probably require analyzing all building recipes when tagging.

[gmpinder]

To be clear, @gerblesh , you're just suggesting adding extra tags to the same image and not trying to create some multi build paradigm right? I'm still a little confused as to where the direction is going for these threads.

[xynydev]

The problem I outlined at the start of this thread would be elegantly solved by gerblesh's suggestion, if I'm interpreting it correctly. By default, images would be tagged like they are now. If someone chooses to declare some custom tags, those overwrite the latest tag.
So you could have a recipe-38.yml and recipe-39.yml, which both build the same image name, but the 38 version declares a gts tag. (Actually, the recipes should probably be named recipe-gts.yml and recipe-latest.yml but you get the point.)