Consider switching CI to Azure Pipelines #4577
Labels
C-question
Category: Questions
S-needs-discussion
Status: Needs further discussion before merging or work can be started
Comments
Manishearth
added
S-needs-discussion
|
👍 I know tracing is using azure and I've only heard positive things. I bet this is a win. |
|
Seems like a good idea 👍 I can't come up with anything that our current setup has that Azure doesn't have. Some things that are currently travis specific:
|
|
Sounds good. Especially the "supports all three OSes" part, since we tried pretty often to use the travis windows build, without success. #3418 #4004 #4320 #4324 #3306 #3484 #3486 ... (way too often 😄)
This type of secret key is normally used for ssh deployment from travis. We're using them here: Lines 60 to 65 in 1366629 |
|
Small Rust projects mostly use Github Actions now but I don't know if it'd suffice for Clippy. |
|
Even though I think GitHub Actions is a good CI/CD tool, I don't think that it is quite there yet, to support a project like Clippy. So I'd vote for Azure, if at all possible. |
|
Yep, and when I asked infra folks they also suggested using Actions (because of the then-not-public switch linked above) |
bors
added a commit
that referenced
this issue
Nov 23, 2019
[WIP] RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) Based on #4825, so I could test it. changelog: none
bors
added a commit
that referenced
this issue
Nov 23, 2019
[WIP] RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) changelog: none
bors
added a commit
that referenced
this issue
Nov 25, 2019
[WIP] RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) changelog: none
bors
added a commit
that referenced
this issue
Nov 28, 2019
RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) changelog: none
bors
added a commit
that referenced
this issue
Nov 29, 2019
RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) changelog: none
bors
added a commit
that referenced
this issue
Nov 29, 2019
RIIR: Integration tests In #4825 the `rust-lang/chalk` test failed because the output was too large. I didn't want to completely disabling the output, since showing the backtrace of an ICE directly in travis is pretty useful. Since finding strings in command outputs is easier in Rust, than in bash, I just RIIRed it. This and also rewriting our tests in Rust may help with trying out new CI platforms (cc #4577) changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. Also IIUC we only have to build Clippy once for every initegration test and then only check the repos. changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. Also IIUC we only have to build Clippy once for every initegration test and then only check the repos. changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. Also IIUC we only have to build Clippy once for every initegration test and then only check the repos. changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. Also IIUC we only have to build Clippy once for every initegration test and then only check the repos. changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 20, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 21, 2020
[WIP][DNM] Switch to GitHub Actions (maybe?) cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io#1838) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io#1838) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 23, 2020
[WIP][DNM] Switch to GitHub Actions cc #4577 This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor. GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [ ] Add `DEPLOY_KEY` secret to github repo - [ ] test deployment on test branch `gh-test` - [ ] talk with `@rust-lang/infra` for bors - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io#1838) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
11 tasks
bors
added a commit
that referenced
this issue
Jan 30, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this)~~ That seems to start working again yesterday 🤔 Let's hope it keeps working. - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 30, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this)~~ That seems to start working again yesterday 🤔 Let's hope it keeps working. - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 30, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this)~~ That seems to start working again yesterday 🤔 Let's hope it keeps working. - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?)
bors
added a commit
that referenced
this issue
Jan 30, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?)
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?)
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Jan 31, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on `rust-lang/crates.io#1838`) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 4, 2020
[WIP][DNM] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [ ] Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142 - [ ] impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass - [ ] Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838) - [ ] Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/ - [ ] Add back travis + appveyor files for transition period (?) changelog: none
bors
added a commit
that referenced
this issue
Feb 7, 2020
[WIP] Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday 🤔 Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142~~ We need to run the bors tests unconditionally anyway (47138d1) so it doesn't really matter. - [ ] impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass. The bors dummy jobs are added in 1a83b7a and work as expected: #5088 (comment). I opened rust-lang/rust-central-station#578 - [x] ~Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838)~ Added a FIXME in 2332b57 - [x] ~Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/~ WIll probably not be implemented in the near future. - [x] Add back travis + appveyor files for transition period (!) changelog: none
bors
added a commit
that referenced
this issue
Feb 12, 2020
Switch to GitHub Actions - Part 2 - From within This is a continuation of #5071. This time from a branch inside the rust-lang/rust-clippy repo, not from my fork, since secrets are not available in PRs from forks. Copying the description of #5071 to here: Closes #4577 ~~This is just an experiment. I don't think we have a consensus _if_ we should move away from travis/appveyor.~~ We have consensus: #5071 (comment) ~~GHA would let us run up to 20 concurrent jobs. Since we have 15 integration tests and 4 (linux, linux 32-bit, macos, windows) basic tests, we would be able to run everything concurrently.~~ The org has a limit of 60 jobs across the org, so we limit the matrix of the integration tests to 6 concurrent jobs. ~~Also IIUC we only have to build Clippy once for every initegration test and then only check the repos.~~ Nope, dependent jobs exist, but they won't keep the artifacts (not even the checkout). TODO before merge: - [x] Add `DEPLOY_KEY` secret to github repo - [x] test deployment on test branch `gh-test`# - [x] Test normal deployment - [x] Test deployment no changes - [x] Test deployment of tag - [x] talk with `@rust-lang/infra` for bors, `@rust-lang/infra` is good with the move (crater also uses GHA+bors) - [x] ~~Get remark + clippy_dev check to work on pushes (https://github.community/t5/GitHub-Actions/~Builds-are-not-triggered-with-on-paths/m-p/44075; I contacted GH support about this) ~~That seems to start working again yesterday. Let's hope it keeps working.~~ Or not: df9be48. Now it works again: 723786a. I think we should wait, until this is reliable. It appears, that it doesn't work on force pushes (sometimes?): 5814142~~ We need to run the bors tests unconditionally anyway (47138d1) so it doesn't really matter. - [x] ~~impl homu checks for GHA #5071 (comment) -- I prepared: flip1995/rust-central-station@f40230d. I'd suggest to first add GHA and keep the travis and appveyor checks for a few days and to remove them in a second pass. The bors dummy jobs are added in 1a83b7a and work as expected: #5088 (comment). I opened rust-lang/rust-central-station#578 See #5088 (comment) - [x] ~Add GHA badge to Cargo.toml (blocked on rust-lang/crates.io # 1838)~ Added a FIXME in 2332b57 - [x] ~Maybe we should also wait until GHA supports yaml anchors. https://github.community/t5/GitHub-Actions/Support-for-YAML-anchors/td-p/30336/~ WIll probably not be implemented in the near future. - [x] Add back travis + appveyor files for transition period (!) changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
rustc has moved to it, and it seems overall nicer. It supports all three OSes, and it also supports better pipelining. So, for example, one can build clippy first, and then parallelize the integration tests based on a single clippy build (instead of having ten integration test workers all build clippy). This should be faster, and we might benefit from the Rust org's azure builders, though we'd have to check with the infra team on that (@pietro?).
thoughts? @phansch @flip1995 @oli-obk @yaahc
The text was updated successfully, but these errors were encountered: