arriving at a stable, functional, and sensical recipe standard

[xynydev]

(this issue is filed under CLI, because this is the only place changes would have to be made to implement changes to the recipe format)

I had an epiphany. But let me preface a bit; if the purpose of the recipe is to be a versatile standard that describes the build and publish process of a native container image, is it as good as that as can be? And if not, aren't we in the broad ideal moment of time to evolve it?

Here's how it could look:

base-image:
    url: ghcr.io/ublue-os/silverblue-main
    tag: 40
    public-key: https://... # unimplemented, needed for base image verification, would be optional, and automatically supplied for ublue etc.
    type: ostree # unimplemented, might be needed for effectively supporting different base images, which might need things like running `ostree container commit` 
result-image:
    name: weird-os
    description: This is my personal OS image.
    tags: # replaces the "latest" and timestamp tags
       - gts
stages:
    ...
modules:
    ...

That's a sketch, but IMO it's already better than what we have now. Ideas and discussion appreciated here, though.

Multiple versions of the recipe standard could be supported in a way similar to other projects, say, docker-compose.yml do. I'd opt for using the $schema: key to specify the version; that would force us to supply jsonschema for all supported versions, and the user to update both the autocomplete source and the actual version in their recipes at the same time. This would set a solid foundation for breaking recipe changes in the future. If rust can do jsonchema validation, maybe we could even get multi-version support in CLI with not much extra effort? #173

@blue-build/members

[fiftydinar]

Generally looks good.

    tags: # replaces the "latest" and timestamp tags
       - gts

I'm interested in this part.

It would be possible to provide multiple tags, like gts & latest, right?

What about other images, like VanillaOS, which have different release schedules?
I guess that only latest would be supplied short-term, while gts is more of a Fedora/Universal Blue thing.
Maybe the equivalent for it would be lts, but not sure. Just thinking around.

[xynydev]

Yes, that's an already implemented feature, and can be used to set any set of custom tags on any image. latest is added automatically if tags isn't set, but after that, it's up to the user.

[gmpinder]

I think this structure makes way more sense TBH. I do think that result-image: could be something else like final-image or main-image. The public key property is a good addition too. I was envisioning adding our own labels onto images that would be a link to the public key or something like that. This way we would be able to pull that information dynamically on build. But this property would be perfect for images that aren't built by bluebuild.

[gmpinder]

Something else that could probably be added later for the user's image is labels: which would just be a map

[gmpinder]

As for the "schema" for the recipe, the struct definitions and the use of serde already act like a schema enforcer. However, I think using schema's for the configuration of modules would be a really good idea to be able to validate the input before building.

[gmpinder]

So there is a jsonschema crate that we can use that is being actively maintained it would seem. Also we could include a tool to convert user's recipes using struct-convert. I used this at work for helping to create a helm values migration tool for deploying our services.

[gmpinder]

base-image:
    url: ghcr.io/ublue-os/silverblue-main

Just realized. I don't think this should be url:. Image refs are their own separate spec from URL. Maybe name, from, image-name, ref. I just think URL is misleading a bit.

[xynydev]

base-image:
    url: ghcr.io/ublue-os/silverblue-main

Just realized. I don't think this should be url:. Image refs are their own separate spec from URL. Maybe name, from, image-name, ref. I just think URL is misleading a bit.

Yeah I was a bit iffy on that too, but don't know what would be better. from isn't that clear either IMO. ref could be? Will have to see how it's referred to in the spec.

[xynydev]

I do think that result-image: could be something else like final-image or main-image.

Maybe final-image then, definetly not main-image, that's an overloaded term. metadata would be another possible key name for it.

[gmpinder]

Maybe final-image then, definetly not main-image, that's an overloaded term. metadata would be another possible key name for it.

I like metadata. Feels k8s-ish

[fiftydinar]

final-image is better imo, metadata can be referred to almost anything that contains information.

[xynydev]

To spin that argument around: basically everything in the recipe concerns 'the final image', while metadata would quite literally be the final images metadata, as in it's name, description, labels, etc.