Skip to content
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

Consider switching CI to Azure Pipelines #4577

Closed
Manishearth opened this issue Sep 25, 2019 · 7 comments · Fixed by #5088
Closed

Consider switching CI to Azure Pipelines #4577

Manishearth opened this issue Sep 25, 2019 · 7 comments · Fixed by #5088
Labels
C-question Category: Questions S-needs-discussion Status: Needs further discussion before merging or work can be started

Comments

@Manishearth
Copy link
Member

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

@Manishearth Manishearth added S-needs-discussion Status: Needs further discussion before merging or work can be started C-question Category: Questions labels Sep 25, 2019
@yaahc
Copy link
Member

yaahc commented Sep 26, 2019

👍

I know tracing is using azure and I've only heard positive things. I bet this is a win.

@phansch
Copy link
Member

phansch commented Sep 26, 2019

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:

  • .github/deploy.sh is using some TRAVIS_ env variables
  • ci/base-tests.sh uses TRAVIS_OS_NAME
  • We have two encrypted variables in the Travis config UI, which I don't know what they are used for
  • Our bors setup needs to be updated as well, I believe

@flip1995
Copy link
Member

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 😄)

We have two encrypted variables in the Travis config UI, which I don't know what they are used for

This type of secret key is normally used for ssh deployment from travis. We're using them here:

ENCRYPTION_LABEL=e3a2d77100be
ENCRYPTED_KEY_VAR="encrypted_${ENCRYPTION_LABEL}_key"
ENCRYPTED_IV_VAR="encrypted_${ENCRYPTION_LABEL}_iv"
ENCRYPTED_KEY=${!ENCRYPTED_KEY_VAR}
ENCRYPTED_IV=${!ENCRYPTED_IV_VAR}
openssl aes-256-cbc -K "$ENCRYPTED_KEY" -iv "$ENCRYPTED_IV" -in .github/deploy_key.enc -out .github/deploy_key -d

@mati865
Copy link
Contributor

mati865 commented Oct 3, 2019

Small Rust projects mostly use Github Actions now but I don't know if it'd suffice for Clippy.

@flip1995
Copy link
Member

flip1995 commented Oct 4, 2019

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.

@mati865
Copy link
Contributor

mati865 commented Nov 14, 2019

@Manishearth
Copy link
Member Author

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
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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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://gh.neting.ccmunity/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 bors closed this as completed in 71a5379 Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-question Category: Questions S-needs-discussion Status: Needs further discussion before merging or work can be started
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants