Tracking: Introduce proper trunk/backport workflow

For now every rustup release is directly merged onto trunk and thus we might want to block patch releases from happening once a major/breaking change has landed (or vice versa). This is not very practical.

To keep and even further increase the bandwidth and momentum, an important change we would need to make to the current workflow would be to allow people from both inside and outside of the project to contribute whenever they want, and for the changes to land in the right release in a more flexible timeframe, so that we can introduce major changes even when we are waiting for patch releases. Thus the desire for a backport branch that collects all the bugfixes in this minor cycle, with proper CI and even CD (when the new release process is ready), from which we will force-push our stables.

Surely this needs more bandwidth, so it will probably not happen immediately, but I can see that this might be an important step in ensuring the project's long term health.

Tasks

We could maybe ask if anyone from infra would help set up a stable branch (maybe a beta branch too?). Even if we can't make much use of it to start with, having something to build on would be useful.

@ChrisDenton

@ChrisDenton The current stable branch is a placeholder for "what we want to deploy as the next release" but the semantics is too ambiguous it seems to me: we reuse it for every beta and every stable, and there's no guarantee that at a given point in time what that would be. I'm thinking about branches like X.YY with proper CI so that we can at least have something to track.

For other projects I usually have branches like 1.29.x once main has incompatible changes and a maintenance release needs to be made. But IMO there is not much point in making these branches proactively, since you can always make them when needed?

I thought the hard part was not creating the branches themselves (that's of course easy) but that all our infrastructure is based on the current setup (CI scripts, etc).

@ChrisDenton

I thought the hard part was not creating the branches themselves (that's of course easy) but that all our infrastructure is based on the current setup (CI scripts, etc).

@ChrisDenton Exactly. For now a reasonable next step for us seems to be that:

Versioned backport branches get full CI both during backport PRs and upon push.
- Unlike trunk where we also have the more scheduled "heavy CI runs", on versioned backport branches they are disabled.
- Nonetheless, we should have a mechanism to trigger heavy CI on demand on those branches without having to use the config on other branches.
Change the release process so that the stable branch only serves as a staging area for releases. This will notably include force-pushing from any writer to this repo.

So this is my plan: upon the next incompatible change please feel free to tell me, I'll create a branch named backport/1.29 (feel free to suggest alternative prefixes) and I'll coordinate with the mods to put force-push bans on backport/* branches, and yes they should have merge queue enabled as well :)

Once that's done I'll take care of CI on those branches.

Pseudo-main CI on release/* is running right now: https://github.com/rust-lang/rustup/actions/runs/23918294937

Notably, the GitHub Actions artifacts are uploaded as usual, but no other deployment steps has been triggered 🚀

Next up, I'll:

~~Verify that the in-queue workflows are working identically to the occasions when we target trunk.~~ Impossible, see the update in the original post.
Investigate if it's practical to trigger "heavy" CI on release/* on demand.

Actually the latter part can wait for a bit, since we already have stable as the final resort if that doesn't work out. Thus, it only adds more confidence rather than blocking the backport flow from happening.

I have confirmed that with #4796, we can now run the equivalent of scheduled task manually:

# Run on trunk
> gh workflow run ci.yaml

# Run on backport
> gh workflow run ci.yaml --ref release/1.29-dummy
This should be helpful for occasionally running the full CI on backport branches, and in the meantime we won't have to wait for the scheduled run on trunk again if the situation is urgent.

When the whole process is done, I'll update the dev docs to reflect the new procedure.

The release/1.29-dummy branch has completed its mission, deleting...

Next up: branching off as per our new release process and prepare for the v1.29.1 release.

@Kobzol

@Kobzol I deeply appreciate your previous efforts in #4805 in which I promised an update when the trial is over. Now here it is :)

I tried in my personal project and it still seems feasible to at least enable the "require status check" for PRs targeting our backport branches while leaving "require a pull request" disabled. This means in that case I can still push to the topic branch if desired, so this will give us the level of flexibility we want:

Otherwise, your explicit settings look good to me:

[[branch-protections]]
pattern = "release/*"
ci-checks = ["conclusion"]
required-approvals = 0
prevent-creation = false

Requiring status checks without requiring a PR doesn't make much sense, because you can't run status checks without opening a PR 😅 (Maybe unless the status checks already ran on the same commit previously in a different branch/PR? 🤔 Not sure if GitHub works like this). Unless we enable bypassing the status check rule for specific teams.

@Kobzol

Requiring status checks without requiring a PR doesn't make much sense, because you can't run status checks without opening a PR

@Kobzol That's correct, but according to my experiment this has also made it possible to have auto-merge on PRs targeting this branch so there are some real benefits after all.

My theory is that for low-bandwidth branches such as the backport ones having auto-merge is close enough to having a proper merge queue.

Auto merge is a separate checkbox in the repository configuration, though it does indeed require status checks, otherwise it wouldn't work.

But again, you can't have required status checks without requiring a PR. GitHub would simply reject your git push.

@Kobzol

@Kobzol My apologies, but there must have been a misunderstanding somewhere: both the screenshot above (#4738 (comment)) and GitHub's docs seem to suggest that "require a pull request" and "require status check" are two independent options.

That said, I now do agree with you that we should enable both for our case to avoid further confusions, in addition to the auto-merge one, if possible.

Yeah they are independent, but if you enable only "require status check", it becomes impossible to merge anything without a PR - GitHub is fine with that apparently 😆

That being said, it can be made to work if you enable bypass actors. If you enable "require status checks", but not "require a PR", then when you push, you will be met with this:

remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: 
remote: - Required status check "Test merge queue" is expected.
To https://github.com/<foo>
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/<foo>

If you add bypass actors, then specified teams (e.g. those with write access) will be able to push. And when a PR is opened, the PR will have to be green in order to be merged, unless you are a bypass actor, and you click on the following checkbox (which can be used to bypass the PR CI check):

Is that ok for you?

@Kobzol

@Kobzol Ah that explains, in my repo for this experiment we do have bypass actors enabled indeed, never thought that was related though.

Let's do that then! Many thanks again for the thorough investigation! 🙏

Update: Merged rust-lang/team#2437.

Closed by #4958 and rust-lang/simpleinfra#1178.

Navigation Menu

Repository navigation

Tracking: Introduce proper trunk/backport workflow #4738

Tasks

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking: Introduce proper trunk/backport workflow #4738

Description

Tasks

Activity

ChrisDenton commented on Mar 5, 2026

rami3l commented on Mar 5, 2026

djc commented on Mar 5, 2026

ChrisDenton commented on Mar 5, 2026

rami3l commented on Mar 5, 2026

rami3l commented on Mar 16, 2026

rami3l commented on Apr 2, 2026

rami3l commented on Apr 5, 2026

rami3l commented on Apr 16, 2026

rami3l commented on Apr 17, 2026

Kobzol commented on Apr 17, 2026

rami3l commented on Apr 17, 2026

Kobzol commented on Apr 17, 2026

rami3l commented on Apr 17, 2026

Kobzol commented on Apr 19, 2026

rami3l commented on Apr 19, 2026

rami3l commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions