Learn more about these different git repos.
Other Git URLs
The fedora and fedora-minimal container repositories have images that are tagged "latest" and "rawhide".
It would be useful to add a "branched" tag (or similar), which refers to the image for the Branched release. Currently, the tag for its release number ("40") must be used instead. This would allow CI pipelines to automatically run jobs for Branched, without needing to update the tag used each release cycle.
Metadata Update from @phsmoura: - Issue tagged with: low-gain, low-trouble
Metadata Update from @phsmoura: - Issue tagged with: ops
So, we could do this, but... how would it work when there isn't a branched release?
Should we remove the tag/alias when a release happens?
Then people could only depend on it existing some times?
Perhaps we could provide a recipe for getting this information from bodhi instead?
Metadata Update from @kevin: - Issue untagged with: ops
So, we could do this, but... how would it work when there isn't a branched release? Should we remove the tag/alias when a release happens? Then people could only depend on it existing some times?
I would suggest keeping the tag in place all the time. When there isn't a branched release, the tag wouldn't get updated; it would just remain pointed to the stable release.
That's consistent with the way composes for Branched are stored here. (See this snapshot from January.)
The idea is to avoid that. Consider, for example, how someone would use GitHub Actions to run a job for Branched. It would be simplest to have a fixed tag that could be used in the YAML file.
That seems confusing to me. How do you know you are using branched or a stable release? Perhaps better the tag could be 'branched-or-stable' or something?
Those are composes. When we do a release we make RC's and then when one is 'go' for release, we stop making branched. The RC is the thing thats released. People should NOT point to compose areas.
Perhaps we could provide a recipe for getting this information from bodhi instead? The idea is to avoid that. Consider, for example, how someone would use GitHub Actions to run a job for Branched. It would be simplest to have a fixed tag that could be used in the YAML file.
Yeah, understandable. I think 'branched' isn't really descriptive enough of what we would point it to...
Login to comment on this ticket.