-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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.
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
chore: detect the channel a PR wants to merge into #12181
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
|
.github/workflows/main.yml
Outdated
name: Tests ${{ matrix.name }} | ||
steps: | ||
- uses: actions/checkout@v3 | ||
if: matrix.if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately job.if
cannot access fields in matrix
. We cannot simply write if: matrix.if
for job
and instead we need to do it in each step
. That's terrible. Totally understand if someone objects to this PR due to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, that is really unfortunate. Is it possible to use something like https://stackoverflow.com/a/65434401 to have a job that runs first to generate the matrix? I'm not sure if that's any better, since it is also a pretty complex solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 4ff82fd. Doesn't look too bad though.
32bae81
to
a085f16
Compare
ci/which-channel.sh
Outdated
beta="$(rustc +beta -V)" | ||
stable="$(rustc +stable -V)" | ||
|
||
if [[ "$beta" == "rustc ${version}"* ]] | ||
then | ||
CHANNEL="beta" | ||
fi | ||
|
||
if [[ "$stable" = "rustc ${version}"* ]] | ||
then | ||
CHANNEL="stable" | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned that this looks to assume that beta
gets published when it branches. However, it isn't uncommon for it to take a few weeks, and I know in the past we have needed to merge changes to cargo soon after the beta branch.
Perhaps that isn't a big deal, since the divergence of nightly and beta isn't that large, but this seems a little fragile. Would it be possible to say if the base ref matches the rust-1.*.0
pattern to assume it is for beta, and only set it to stable if rustc +stable -V
matches?
Another option, instead of downloading rustc
at all is to list all the rust-*
branches, sort them, and see if the current branch is the last one, and assume it is beta? Otherwise, assume it is stable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way looks more robust to me. I'll try the latter since it reduces one toolchain download.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 6a973cf.
ci/which-channel.sh
Outdated
ref=$(git name-rev --name-only --refs="origin/rust-1.*" $base_sha) | ||
|
||
# Remove the patch version `.0` and keep only `1.y`, | ||
# so that rustup can install the correct patched toolchain | ||
if [[ "$ref" =~ ^origin/rust-(.*).0$ ]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit uncertain about how this works, perhaps you can clarify.
Locally running git name-rev
, my output looks like origin/rust-1.69.0~1
where there is a ~
character. But the regex here doesn't allot for that. I'm a bit confused by that.
Also, does this work if I open a PR to a beta branch, but my commit is a few commits behind the tip of the branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The assumption here is that a base_sha
is always HEAD ofrust-1.*.0
branch. It either gets the commit from github.event.pull_request.base.sha
, or from bors merge-commit~1
. If this assumption is correct, I think git name-rev
will always get a ref without ~
or ^
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 6a973cf.
9313c6f
to
43ae784
Compare
ci/which-channel.sh
Outdated
|
||
# Get the latest `rust-1.*.0` branch from remote origin. | ||
# Assumption: The latest branch is always beta branch. | ||
beta=$(git branch --remotes --list 'origin/rust-1.*.0' | sort | tail -n1 | tr -d "[:space:]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it might have some issues with three-digit version like 1.100. Perhaps it could be something like sed -E 's/ *upstream\/rust-1.([0-9]+).0/\1/g' | sort -n
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went using sort --version-sort
. Tested on ubuntu-latest (22.04). It can correctly sort the following versions from
origin/rust-1.100.0
origin/rust-1.50.0
origin/rust-1.222.0
origin/rust-1.48.0
origin/rust-1.70.0
origin/rust-1.60.0
origin/rust-1.69.0
origin/rust-1.9.0
to
origin/rust-1.9.0
origin/rust-1.48.0
origin/rust-1.50.0
origin/rust-1.60.0
origin/rust-1.69.0
origin/rust-1.70.0
origin/rust-1.100.0
origin/rust-1.222.0
MATRIX=$( | ||
jq --arg C "$CHANNEL" 'map (. | | ||
if ($C == "beta") then select(.rust | startswith("nightly") | not) | ||
elif ($C == "stable") then select(.rust | startswith("stable")) | ||
else . end)' ci/matrix.json | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this have a comment explaining roughly what it is doing? It's not too hard to follow, but just a high-level description could help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added. Let me know if it is clear enough.
43ae784
to
11704cb
Compare
Thanks for the review! I rebased the pull request. Change diff can be seen from here. |
Thanks! I'm not sure if it matters much that we're merging this to rust-1.70.0, but I think it should be fine. Do you also want to backport this to rust-1.71.0? I kinda wish GitHub Actions would have a little more diagnostics or descriptions on the runs page to explain why a job was skipped, but hopefully it will be clear to people in the future. @bors r+ |
chore: detect the channel a PR wants to merge into ### What does this PR try to resolve? This detects which channel a pull request wants to merge into. It is hard because bors runs in a different repo. Bors knows nothing about branches or tag in this repo. It only see one base commit and a merge commit AFAIK. Basically the assumption and idea are 1. bors create a merge commit, so `HEAD~` should find the base branch. 2. Cargo maintains `rust-1.y.0` branch for each Rust minor version releases. Therefore, we can use the symbolic name of `origin/rust-1.x.0` to determine if it aims for stable, beta, or nightly channel. 3. After we know which channel it is targeted at, we can skip jobs that are likely to be broken. ### How should we test and review this PR? I setup a rust-1.70.0 branch on ec8a8a0 on my repo. The script does find beta branch correctly. https://github.com/weihanglo/cargo/actions/runs/5081469788/jobs/9129891293#step:3:36
Sure for 1.71.0. Now it sounds like we need two more PRs — one for 1.71 beta and the other for master 😂 |
💔 Test failed - checks-actions |
Oops, looks like skipped jobs cause a failure in the |
Ok.
Just kidding. |
Something like this? I can send PRs to 1.71.0 and master and then close this if this patch seems good. diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 2f75f206b..5f955af89 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -227,11 +228,16 @@ jobs:
"https://raw.githubusercontent.com/rust-lang/rust/$BRANCH/src/tools/linkchecker/linkcheck.sh"
sh linkcheck.sh --all cargo
+ nightly-only-jobs:
+ needs: [build_std]
+ if: "(jobs.channel.outputs.CHANNEL != 'master' && contains(needs.*.result, 'skipped')) || success()"
+ runs-on: ubuntu-latest
+
success:
permissions:
contents: none
name: bors build finished
- needs: [docs, rustfmt, test, resolver, build_std, test_gitoxide]
+ needs: [docs, rustfmt, test, resolver, nightly-only-jobs, test_gitoxide]
runs-on: ubuntu-latest
if: "success() && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo'"
steps:
@@ -240,7 +246,7 @@ jobs:
permissions:
contents: none
name: bors build finished
- needs: [docs, rustfmt, test, resolver, build_std]
+ needs: [docs, rustfmt, test, resolver, nightly-only-jobs]
runs-on: ubuntu-latest
if: "!success() && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo'"
steps: |
e38136a
to
5f91c78
Compare
5f91c78
to
40be718
Compare
Okay I've updated this to target on the current master. We can have a new round of review :) |
…r=ehuss [beta-1.71.0] detect the channel a PR wants to merge into ### What does this PR try to resolve? This detects which channel a pull request wants to merge into. It is hard because bors runs in a different repo. Bors knows nothing about branches or tag in this repo. It only see one base commit and a merge commit AFAIK. Basically the assumption and idea are 1. bors create a merge commit, so `HEAD~` should find the base branch. 2. Cargo maintains `rust-1.y.0` branch for each Rust minor version releases. Therefore, we can use the symbolic name of `origin/rust-1.x.0` to determine if it aims for stable, beta, or nightly channel. 3. After we know which channel it is targeted at, we can skip jobs that are likely to be broken. ### How should we test and review this PR? This is like #12181 but targeted on 1.71.0. r? ehuss
@bors r+ |
☀️ Test successful - checks-actions |
… r=epage Revert "chore: detect the channel a PR wants to merge into" Reverts #12181 GitHub Action expression `success()` will look into the chain of dependent jobs. On master CI passed but on a backport it still failed <#12200 (comment)> This isn't worth pursuing at this moment either. To fix it, it's unavoidable to write something like below for bors job ```yaml if: "always() && !(contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') || contains(needs.*.result, 'failure') ) && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo' " ``` I don't think that's good in long-term. r? ehuss
… r=epage Revert "chore: detect the channel a PR wants to merge into" Reverts #12181 GitHub Action expression `success()` will look into the chain of dependent jobs. On master CI passed but on a backport it still failed <#12200 (comment)> This isn't worth pursuing at this moment either. To fix it, it's unavoidable to write something like below for bors job ```yaml if: "always() && !(contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') || contains(needs.*.result, 'failure') ) && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo' " ``` I don't think that's good in long-term. r? ehuss
… r=epage Revert "chore: detect the channel a PR wants to merge into" Reverts #12181 GitHub Action expression `success()` will look into the chain of dependent jobs. On master CI passed but on a backport it still failed <#12200 (comment)> This isn't worth pursuing at this moment either. To fix it, it's unavoidable to write something like below for bors job ```yaml if: "always() && !(contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') || contains(needs.*.result, 'failure') ) && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo' " ``` I don't think that's good in long-term. r? ehuss
Update cargo 17 commits in 64fb38c97ac4d3a327fc9032c862dd28c8833b17..f7b95e31642e09c2b6eabb18ed75007dda6677a0 2023-05-23 18:53:23 +0000 to 2023-05-30 19:25:02 +0000 - chore: detect the channel a PR wants to merge into (rust-lang/cargo#12181) - refactor: de-depulicate `make_dep_prefix` implementation (rust-lang/cargo#12203) - Re-enable code_generation test on Windows (rust-lang/cargo#12199) - docs: add doc comments for git source and friends (rust-lang/cargo#12192) - test: set retry sleep to 1ms for all tests (rust-lang/cargo#12194) - fix(add): Reduce the chance we re-format the user's `[features]` table (rust-lang/cargo#12191) - test(add): Remove expensive test (rust-lang/cargo#12188) - Add a description of `Cargo.lock` conflicts in the Cargo FAQ (rust-lang/cargo#12185) - refactor(tests): Reduce cargo-add setup load (rust-lang/cargo#12189) - Warn when an edition 2021 crate is in a virtual workspace with default resolver (rust-lang/cargo#10910) - refactor(tests): Reduce cargo-remove setup load (rust-lang/cargo#12184) - chore: Lexicographically order `-Z` flags (rust-lang/cargo#12182) - chore(ci): remove temporary fix for rustup 1.24.1 (rust-lang/cargo#12180) - fix: AIX searches dynamic libraries in `LIBPATH`. (rust-lang/cargo#11968) - deps: remove unused features from windows-sys (rust-lang/cargo#12176) - Automatically inherit workspace lints when running cargo new/init (rust-lang/cargo#12174) - Test that the new `debuginfo` options match between cargo and rustc (rust-lang/cargo#12022) r? `@ghost`
Update cargo 17 commits in 64fb38c97ac4d3a327fc9032c862dd28c8833b17..f7b95e31642e09c2b6eabb18ed75007dda6677a0 2023-05-23 18:53:23 +0000 to 2023-05-30 19:25:02 +0000 - chore: detect the channel a PR wants to merge into (rust-lang/cargo#12181) - refactor: de-depulicate `make_dep_prefix` implementation (rust-lang/cargo#12203) - Re-enable code_generation test on Windows (rust-lang/cargo#12199) - docs: add doc comments for git source and friends (rust-lang/cargo#12192) - test: set retry sleep to 1ms for all tests (rust-lang/cargo#12194) - fix(add): Reduce the chance we re-format the user's `[features]` table (rust-lang/cargo#12191) - test(add): Remove expensive test (rust-lang/cargo#12188) - Add a description of `Cargo.lock` conflicts in the Cargo FAQ (rust-lang/cargo#12185) - refactor(tests): Reduce cargo-add setup load (rust-lang/cargo#12189) - Warn when an edition 2021 crate is in a virtual workspace with default resolver (rust-lang/cargo#10910) - refactor(tests): Reduce cargo-remove setup load (rust-lang/cargo#12184) - chore: Lexicographically order `-Z` flags (rust-lang/cargo#12182) - chore(ci): remove temporary fix for rustup 1.24.1 (rust-lang/cargo#12180) - fix: AIX searches dynamic libraries in `LIBPATH`. (rust-lang/cargo#11968) - deps: remove unused features from windows-sys (rust-lang/cargo#12176) - Automatically inherit workspace lints when running cargo new/init (rust-lang/cargo#12174) - Test that the new `debuginfo` options match between cargo and rustc (rust-lang/cargo#12022) r? `@ghost`
What does this PR try to resolve?
This detects which channel a pull request wants to merge into.
It is hard because bors runs in a different repo.
Bors knows nothing about branches or tag in this repo.
It only see one base commit and a merge commit AFAIK.
Basically the assumption and idea are
HEAD~
should find the base branch.rust-1.y.0
branch for each Rust minor version releases.Therefore, we can use the symbolic name of
origin/rust-1.x.0
to determine if it aims for stable, beta, or nightly channel.
we can skip jobs that are likely to be broken.
How should we test and review this PR?
I setup a rust-1.70.0 branch on ec8a8a0 on my repo.
The script does find beta branch correctly.
https://github.com/weihanglo/cargo/actions/runs/5081469788/jobs/9129891293#step:3:36
Additional information
Sorry for bringing more shell scripts 🤯.
If this looks good, I'll file a PR for master branch.