Skip to content

ci(backport): test workflow#4792

Open
rami3l wants to merge 1 commit intorust-lang:release/1.29-dummyfrom
rami3l:x/backport-workflow
Open

ci(backport): test workflow#4792
rami3l wants to merge 1 commit intorust-lang:release/1.29-dummyfrom
rami3l:x/backport-workflow

Conversation

@rami3l
Copy link
Copy Markdown
Member

@rami3l rami3l commented Mar 31, 2026

Part of #4738.

This PR adds a joke to the README.

@djc
Copy link
Copy Markdown
Contributor

djc commented Mar 31, 2026

I'm not that into it. But if someone else likes it, I can live with it.

@rami3l
Copy link
Copy Markdown
Member Author

rami3l commented Mar 31, 2026

@djc This change is explicitly made absurd to test the backporting workflow (so that you will never merge it by accident into trunk, see the branch name and the target branch), don't panic XD

@rami3l rami3l changed the title docs(readme): add a joke ci(backport): test workflow Mar 31, 2026
@rami3l

This comment was marked as resolved.

@rami3l

This comment was marked as resolved.

@rami3l
Copy link
Copy Markdown
Member Author

rami3l commented Mar 31, 2026

One special thing about this PR is, of course, it has neither "enqueue" nor "wait for approval" options. I was just reminded that those will only appear in the PRs created after the branch rule modifications, so maybe I'll need to adjust the checklist a bit...

@Kobzol Speaking of #4738, could we have the merge queue enabled for release/* branches gated on the conclusion job just like we do now with main, but without any branch protection rules/approval requirements (yet)? Such modifications will be very useful in the testing phase.

@rami3l
Copy link
Copy Markdown
Member Author

rami3l commented Mar 31, 2026

conclusion passed perfectly, the pre-enqueue jobs are identical to regular PRs targeting main.

@rami3l rami3l force-pushed the x/backport-workflow branch from 6a6baf0 to 0761c18 Compare April 1, 2026 06:27
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 1, 2026

This PR was rebased onto a different release/1.29-dummy commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@Kobzol
Copy link
Copy Markdown
Member

Kobzol commented Apr 1, 2026

@Kobzol Speaking of #4738, could we have the merge queue enabled for release/* branches gated on the conclusion job just like we do now with main, but without any branch protection rules/approval requirements (yet)? Such modifications will be very useful in the testing phase.

Technically you need a branch protection or a ruleset to enable a merge queue, but that doesn't mean that you also must configure approval requirements, so yes, that should be possible.

@rami3l
Copy link
Copy Markdown
Member Author

rami3l commented Apr 1, 2026

Technically you need a branch protection or a ruleset to enable a merge queue, but that doesn't mean that you also must configure approval requirements, so yes, that should be possible.

@Kobzol Cool. What is the absolute minimal branch protection we can enable in order to get the queue going? Can we try that on release/* branches first? Many thanks in advance 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants