search

canonical / rockcraft

Tool to create OCI Images using the language from Snapcraft and Charmcraft.
GNU General Public License v3.0
35 stars 43 forks source link

Feature Request: tag configuration option #213

Closed jardon closed 1 year ago

jardon commented 1 year ago

Hello!

It seems that the packing process uses the version field to tag the resulting artifact. Could a tag field be exposed that allows overriding the tag? The use case is where we want the version field to hold the payload version where we want the tag to include the version payload as well as the base and risk (ie <version>-<base>_<risk>). This allows us to store the payload version metadata inside of the rockcraft.yaml The workaround right now is to retag the image after creation which requires a couple of extra steps.

Thoughts? I am open to other options. If microk8s had an option to retag on an image import, I would be okay with that, but afaik, that is not possible.

sergiusens commented 1 year ago

I am slightly confused, risks are dynamic and not a property of the OCI image itself. The base would also be dynamic across time, unless used as a base for building other images, where a channel track would make sense here.

From a registry point of view, I can see all these being dynamically generated from the channel map.

@cjdcordeiro might have more thoughts on this.

jardon commented 1 year ago

We wanted to mirror the tag format that exists in other images in docker hub as seen here for example. Is there another way to do this outside of tagging directly?

Edit: I think I understand what you are saying about risk being dynamic. So retagging the image would be necessary either way as an image moves from risk to risk.

cjdcordeiro commented 1 year ago

I understand the demand, but I agree with @sergiusens : risks are dynamic, and the same ROCK can move between risks (and even tracks, if we want to go that far).

With a ROCKS Store in place, you'd eventually see something like a canonical tag, that (alike snaps) would be mainly driven by the revision number of the ROCK. But even then, that's a store-based concept, and Rockcraft cannot define those.

In conclusion, yes you always need to tag the ROCK post-build. You can easily do this with something like: skopeo copy oci-archive:<rock-file> docker://<repo>/<img-name>:<tag>

Hope that helps