[WIP][DNM] Switch to GitHub Actions#5071
Conversation
|
@bors try |
[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
|
^ This should run integration tests through GHA. |
|
@bors try |
[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 try |
[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 try |
[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 try |
[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 try |
[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 try |
[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 try |
[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
|
And now with cache @bors r+ |
|
📋 Looks like this PR is still in progress, ignoring approval. Hint: Remove [WIP] from this PR's title when it is ready for review. |
This is already checked by clippy_dev.yml GHA
Keep the fallback to compile-time environment
Some call it the integration integration
|
Try run successful. And it only took 21m32s without a cache vs ~30m on travis with cache. Let's try it with cache (maybe this time remark runs? 🙏): @bors try |
|
💔 Test failed - status-appveyor |
|
12m21 with cache. |
|
@Manishearth can you add a SSH key as a rust-lang/rust-clippy repo secret with the name |
|
@bors try |
|
💔 Test failed - status-appveyor |
|
Remark just won't run on |
|
@bors try |
|
💔 Test failed - status-appveyor |
|
Done! I've added a deploy key, created in the deploy key section of settings. |
Rate limit of 60 applies org wide, let's not spam. Thanks pietroalbini for the hint
|
Closing in favor of #5088 |
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:
DEPLOY_KEYsecret to github repogh-test@rust-lang/infrafor borschangelog: none