feat: Add a new if module property

[gmpinder]

This PR sets up the schema for a new functionality that would allow users to have a module be conditionally executed. Both build-time and template-time on the host.

My main reason for wanting to create something like this was to help with maintaining recipes for various distros and versions. This would allow users to consolidate all their modules for say installing Nvidia drivers for all of their distros into a single recipe module file. Or if you have steps for signing a kernel module (like we do in base-images), having a host-file.exists check for the step that signs modules will be useful for allowing other users/developers that do not have the signing key to build our images locally without it.

Examples

Build-time

Only runs on fedora:

type: dnf
if:
  os-release:
    ID: fedora
install:
  packages:
    - git

Runs based on the os/version:

modules:
  - type: script
    if:
      os-release:
        ID: fedora
        VERSION: 
          - 43
          - 42
    scripts:
      - fedora/nvidiadrivers.sh
  - type: script
    if:
      os-release:
        ID: ubuntu
        VERSION:
          - 24.04
          - 24.10
          - 25.04
          - 25.10
    scripts:
      - ubuntu/nvidiadrivers.sh

Evaluate a shell expression:

type: script
if: '[ -f /some/file ] && command -v git'
snippets:
  - echo "Only runs if /some/file exists and the git command exists"

Template-time

Only runs if the private key exists:

  - type: script
    env:
      PUBLIC_KEY_DER_PATH: /etc/pki/akmods/certs/akmods-blue-build.der
    if:
      host-file:
        exists: ./MOK.priv
    secrets:
      - type: file
        source: ./MOK.priv
        mount: 
          type: file
          destination: /tmp/certs/private_key.priv
    scripts:
      - signkernel.sh

[gmpinder]

I have yet to implement this in the CLI. Just thought I should show the schema we could use before I continue.

[cloudflare-workers-and-pages]

Deploying bluebuild-schema with    Cloudflare Pages

Latest commit:	2341f4d
Status:	✅  Deploy successful!
Preview URL:	https://280786ca.schema-e29.pages.dev
Branch Preview URL:	https://module-if.schema-e29.pages.dev

View logs

[xynydev]

We're all for new features here, but personally stuff like if-statements, build matrixing, etc. inside YAML feels a bit like an identity crisis for recipe.yml.

For me, a recipe.yml is metaphorically the "list of ingredients and which order to add them in" and not a program. These idealized metaphorical recipes are great for many people doing many simple things, but programmers love to program.

That's why I've been (not actively right now, but regardless) looking into YAML-alternatives that would allow more intelligent build matrixing with if statements and such. RCL was the greatest of these I found, although obscure, it worked really nicely with BlueBuild. Of course, the if-statements in RCL are entirely different from those proposed here.

If BlueBuild was a programming framework in a real programming language built on say, a Containerfile-less Buildah workflow, we would have these features almost for free.

Not saying no here, to be clear. I'm saying that the world is not perfect.

[gmpinder]

Not saying no here, to be clear. I'm saying that the world is not perfect.

Well good thing it's already implemented and seems to work really well.

[gmpinder]

a Containerfile-less Buildah workflow

Why did I never know this? This might be the way to go in the future.

[gmpinder]

We're all for new features here, but personally stuff like if-statements, build matrixing, etc. inside YAML feels a bit like an identity crisis for recipe.yml.

I really don't see how adding if statements creates an identity crisis. Any one can can end up writing their own scripts and add conditionals all they want in them. How is that fine but bringing it out to the module level with simple conditions and the ability to write your own POSIX based condition is crossing a line?

RCL was the greatest of these I found, although obscure, it worked really nicely with BlueBuild.

So you're more comfortable moving to an obscure configuration language that requires another external program in order to process it and output a yaml file? Yaml is far more well known. I'm sorry but this doesn't sound like it's based on any technical standing and is more about how you "feel" it should be.

The implementation of this schema prints out the conditions being tested and which one causes the module to be skipped, allowing users to see the decision being made. There is no setting variables. There are no loops. This is not making recipes a programming language any more than writing the scripts themselves.

[xynydev]

So you're more comfortable moving to an obscure configuration language that requires another external program in order to process it and output a yaml file? Yaml is far more well known. I'm sorry but this doesn't sound like it's based on any technical standing and is more about how you "feel" it should be.

Yeah, I guess. But I'm not talking about "moving to", just that "if someone needs complicated build matrixing with if statements etc., there is a tool for that and it works well so we don't have to worry about hacking that feature into YAML". Even the "identity crisis" thing was just something I was feeling (like a slippery-slope gut reaction) and not something "real".

It's like the "well if we have if statements, then we could build multiple different images from the same configuration, so why not also add build matrixing, so why not make the recipe into a function with arbitrary inputs that generates an image as an output" etc. etc.

But of course, this is not that. This is a feature that enables doing maybe some useful things that were not previously possible without custom scripts.

[gmpinder]

There is no setting variables.

I do have to correct myself here, we do have the env property so you can technically set variables but only for the module being ran.

so why not also add build matrixing,

Yeah I think we can leave that to the ci providers or shells.

My goal with these changes is not to implement a full build matrixing. I'm aiming for a way to consolidate modules so that they're easier to manage and include in multiple recipes. Similar on the from-file side of things. It does end up helping with external matrix systems for sure. I think it's fair to say that building a recipe file should only create one (multi-platform bundled) image. It just keeps things simple tbh.