[beta-1.71.0] detect the channel a PR wants to merge into#12200
[beta-1.71.0] detect the channel a PR wants to merge into#12200weihanglo wants to merge 1 commit intorust-lang:rust-1.71.0from
Conversation
|
@bors try |
…r=<try> 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? This is like #12181 but targeted on 1.71.0. r? ehuss
|
Could not assign reviewer from: |
|
|
…r=<try> 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? This is like #12181 but targeted on 1.71.0. r? ehuss
| curl -sSLO "https://raw.githubusercontent.com/rust-lang/rust/$BRANCH/src/tools/linkchecker/linkcheck.sh" | ||
| sh linkcheck.sh --all --path ../src/doc cargo | ||
|
|
||
| # Jobs here must be skipped if they aren't going to merge into master (nightly). |
There was a problem hiding this comment.
Can this comment also explain more about the reason this exists? That is, saying something like "This is needed because GitHub Actions treats success() as false if a job is skipped, and the bors success/failure jobs below need to ignore skipped jobs."
There was a problem hiding this comment.
Now it looks better. Thanks for the suggestion!
8203259 to
a3354a4
Compare
|
Let's @bors try to see if bors can survive with skipped |
…r=<try> 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? This is like #12181 but targeted on 1.71.0. r? ehuss
|
I guess it's good to merge? @rustbot ready |
|
💥 Test timed out |
a3354a4 to
a919c0e
Compare
|
Looks good, thanks! We should probably try to monitor the Actions runs over the next week or two to make sure we didn't make any mistakes with this. It can be tricky when jobs pass when they shouldn't, since it can take a long while for people to notice. @bors r+ |
…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
|
💔 Test failed - checks-actions |
|
Close. See #12204. |
… 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
ci: rewrite bump check and respect semver ### What does this PR try to resolve? This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes #12347. In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier. ### How should we test and review this PR? This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term. For how it works, please the check doc comment in each function. One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back. (Take it easy `@obi1kenobi,` don't be stressed out 🙂) <!-- homu-ignore:end -->
ci: rewrite bump check and respect semver ### What does this PR try to resolve? This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes #12347. In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier. ### How should we test and review this PR? This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term. For how it works, please the check doc comment in each function. One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back. (Take it easy `@obi1kenobi,` don't be stressed out 🙂) <!-- homu-ignore:end -->
ci: rewrite bump check and respect semver ### What does this PR try to resolve? This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes #12347. In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier. ### How should we test and review this PR? This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term. For how it works, please the check doc comment in each function. One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back. (Take it easy `@obi1kenobi,` don't be stressed out 🙂) <!-- homu-ignore:end -->
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.0branch for each Rust minor version releases.Therefore, we can use the symbolic name of
origin/rust-1.x.0to 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?
This is like #12181 but targeted on 1.71.0.
r? ehuss