8000 Release process - tagged commits on branch · Issue #13543 · ComplianceAsCode/content · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Release process - tagged commits on branch #13543

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
21sw-clayton opened this issue Jun 6, 2025 · 3 comments
Open

Release process - tagged commits on branch #13543

21sw-clayton opened this issue Jun 6, 2025 · 3 comments
Labels
triaged

Comments

@21sw-clayton
Copy link
21sw-clayton commented Jun 6, 2025 •
edited
Loading

Downstream background

Yocto Project:

The Yocto Project (YP) is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture.

Yocto is used to build operating systems such as Automotive Grade Linux, Poky (reference distribution), TSEL, and Wind River Linux.

Yocto is industry-standard and has a reference in this project as "openembedded".

Yocto functionality is split into various "layers".

Understanding and Creating Layers:

Layers allow you to isolate different types of customizations from each other.

meta-security (a layer) includes this project ("downstream").

Project commits and branches

The meta-security master branch currently points to v0.1.76 using:
source revision (SRVREV): 616d436
source URI (SRC_URI) using this project's "stable" branch

At the time of the downstream commit, 616d436 was on the stable branch.
Something was changed in this project's branch history, as the commit is no longer on any branch:

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

When this happens, Yocto users are unable to use the recipe:

ERROR: scap-security-guide-0.1.76-r0 do_fetch: Fetcher failure: Unable to find revision 616d436 in branch stable even from upstream

I've also observed this behavior (inconsistently) in previous releases.

Request

Would it be possible to adjust the release process to ensure tagged commits remain on a branch?
@Mab879 Mab879 added the triaged label Jun 12, 2025
@comps
Copy link
Collaborator
comps commented Jun 12, 2025

Would it be possible to adjust the release process to ensure tagged commits remain on a branch?

I've discussed this with other Red Hat maintainers and we might have a proposal (to be put into a PR for discussion at a later point in time).

I don't think it's feasible to have the tagged commits be part of the same linear history of master due to how the "stabilization" process works - this process can take weeks of testing & bug fixing, typically happening in parallel to the continuous master branch development.
Theoretically, as a project, we could decide to pause the merging of PRs during the stabilization phase, effectively switching on some "preparing for release, no wild changes" mode on master, but that might be more widely undesirable.

However, there is a way to keep the stable branch always pointing to the latest tagged release while having previous tagged releases in its history, which is what I think you're asking for.

The solution (to be proposed in a PR at a later point) is to have the stable branch consist of merge commits where

  • The first parent is always a previous (merge) commit on the stable branch
  • The second parent is the released tag

Effectively, this would create a tree like

A
|`-v0.1.77
B
|`-v0.1.76
C
|`-v0.1.75
D
|`-v0.1.74
...

where A,B,C,D,.. are merge commits (with two parents) titled ie. Merge in v0.1.77, and the tag names have full history under them (they are literally the same tagged commit hashes).

The A,B,C,D,.. merge commits would have exactly the same code (repository contents) as the latest merged-in tag. This can easily be double-checked by anyone with git-diff, or simply comparing the git tree object hashes.

Overall, this would effectively fulfill both use cases of

  • I want latest released content without having to hardcode a tag name.
  • I want a fast-forward-able branch that is never suddenly re-created from scratch, follows a contiguous (secured by SHA hashes) history, with all released tags reachable from it (ie. via git-describe).

Does that make sense?

@21sw-clayton
Copy link
Author

Thank you for looking into this @comps!

This proposal appears to address my concerns from a downstream perspective.

I've submitted this: [meta-security][RFC] scap-security-guide do_fetch resolution - upstream release process

This is also a nice bonus (though the Yocto community explicitly prefers fixed revisions):

I want latest released content without having to hardcode a tag name.

Looking forward to the PR

@comps
Copy link
Collaborator
comps commented Jun 12, 2025

Also note that while the approach will likely solve the problem you're seeing, the current approach is valid too - 616d436 is reachable via the v0.1.76 tag.

In git, as long as an object is reachable through another object (blob via tree, tree/commit via another commit) or via what git calls a "ref" (branch, tag, anything under refs/), all is good. If an object (ie. a commit) is not reachable from any of these, it is considered "dangling" and subject to garbage collection.

In this case, 616d436 is not dangling, and having it reachable only from a tag is a perfectly valid scenario. So this looks like a Github UI bug (feature?) because it displays the same message for real dangling commits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
triaged
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Mab879 @comps @21sw-clayton
0