feat: recipe v2 blog

[xynydev]

No description provided.

[github-actions]

💙 Build successful! 💙

Preview deployment: https://recipe-v2-bluebuild-website.xyny.workers.dev/

[xynydev]

@gmpinder

I started writing this, and, well, trying to document something truly might be an ultimate test of whether it makes sense or not.

It turns out, I might have been too eager to approve the Recipe V2 spec as it is...

Here are some things that hurt my brain while writing this:

• I can't justify tags being under spec, because name is under metadata and name is clearly also something very much technical that you pull the image by referring to just like tags... It would make much more sense for name and tags to be under the same category.
• This is not as important, but thinking of this whole metadata thing, somehow it feels weird that name is metadata at all, since it's considered more like the public identifier of the image. But I guess it makes sense somewhat. Metadata just somehow sounds so "optional" to my brain, like of course you could leave the description and labels empty, but I guess the description is mandatory as well... Hmm... Why are the descriptions mandatory btw, I don't think that's a standard thing, it's just a label. Besides, GitHub doesn't even see our base images having any descriptions at all: github link

• If you're not verifying with a public key and you're defining the base image as a ref string and not by parts, it will look like this:

   base:
     image: ghcr.io/blue-build/base-images/fedora-silverblue:gts

  feels a bit odd with the identation and all. I mean I guess it makes sense, I just wish YAML allowed us to write base.image: or something. One could always fix this by allowing base: to be a ref string as well, too. Not sure if it is worth the effort. Something about the snippet above just makes me cringe. I guess it's just YAML, if it was TOML or something It would not look strange to me.

[gmpinder]

The code for this hasn't been written quite yet

[xynydev]

Maybe it should be done before V2 is out?

[gmpinder]

Yes definitely. I'll put it behind a feature flag until it's all ready in case I gotta push a patch out

[gmpinder]

I'm planning on adding a recipe subcommand which will allow upgrading the recipe file automatically, though this process would end up deleting any comments the user added. That way it's easier for the user to upgrade.

[gmpinder]

blue-build/cli#803

[xynydev]

Good call. I shall document this in the announcement as well. I think having both the manual instructions and the automatic method is good, especially since it deletes comments.

[gmpinder]

By default in v2, cosign and nushell won't be automatically installed unless a version is explicitly set, so removing these 2 lines would be equivalent to setting them as none in v1. The bluebuild CLI still follows the v1 pattern though where it's automatically installed since it's our tool.

[xynydev]

Oh, I guess I should refactor this part then. We don't need these tools on image anymore?

Oh and BTW, I don't/didn't think Nushell was ever installed in PATH. At least on my machine I added /usr/libexec/bluebuild/nu to PATH manually for testing purposes. The only purpose of Nushell on the image is to make dependent modules work, and using the BlueBuild Nushell version is very much opt-in.

If it isn't automatically installed, what happens to modules like default-flatpaks? Does Nushell get installed automatically when a dependent module is installed?

[gmpinder]

If it isn't automatically installed, what happens to modules like default-flatpaks? Does Nushell get installed automatically when a dependent module is installed?

Wait are the scripts used by systemd written in nushell? Not just the module?

[xynydev]

Yes, and small CLI bluebuild-flatpak-manager too. They all use a #!/usr/libexec/bluebuild/nu/nu shebang so that Nu need not be in path.

[gmpinder]

Ok, I'll change the logic for nushell then. Cosign isn't needed by default since the CLI has the sigstore crate. That will become the only method the CLI uses for cosign activities in 1.0

[xynydev]

We should probably deprecate cosign installation when it become unused then? There's no need to have a feature in BlueBuild that just installs one program that is not needed IMO.

[gmpinder]

I can't justify tags being under spec, because name is under metadata and name is clearly also something very much technical that you pull the image by referring to just like tags... It would make much more sense for name and tags to be under the same category.

I'm fine with changing it. We haven't released the changes yet.

[gmpinder]

If you're not verifying with a public key and you're defining the base image as a ref string and not by parts, it will look like this:\n\n base:\n image: ghcr.io/blue-build/base-images/fedora-silverblue:gts\nfeels a bit odd with the identation and all. I mean I guess it makes sense, I just wish YAML allowed us to write base.image: or something. One could always fix this by allowing base: to be a ref string as well, too. Not sure if it is worth the effort. Something about the snippet above just makes me cringe. I guess it's just YAML, if it was TOML or something It would not look strange to me.

The whole point was to make the schema more extensible for any new features we might end up adding. Also there's nothing saying we couldn't also support TOML or JSON for the recipes later.

[gmpinder]

Hmm... Why are the descriptions mandatory btw, I don't think that's a standard thing, it's just a label

I'd be fine making it optional.

[gmpinder]

I can't justify tags being under spec, because name is under metadata and name is clearly also something very much technical that you pull the image by referring to just like tags... It would make much more sense for name and tags to be under the same category.

I'm fine with changing it. We haven't released the changes yet.

blue-build/schema#20

[xynydev]

The whole point was to make the schema more extensible for any new features we might end up adding. Also there's nothing saying we couldn't also support TOML or JSON for the recipes later.

Yeah, I don't think we have to do anything about this. It's all fine. It was just something that stuck out to me.

[xynydev]

Hmm... Why are the descriptions mandatory btw, I don't think that's a standard thing, it's just a label

I'd be fine making it optional.

I think it would make sense, but since our template has a description and the description can be an empty string, it's not a huge deal, and we can make the change whenever.