For some reason GHA classifies the bors merges on the master branch as a
push to the auto branch, even though the workflow got triggered by a
push to the master branch. I guess this has something to do with the
same commit hash on master+auto directly after the merge?
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: https://github.com/rust-lang/rust-clippy/pull/5071#issuecomment-576647638
~~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 https://github.com/rust-lang/rust-clippy/pull/5071#issuecomment-576642983 -- I prepared: f40230dc3c. 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 1a83b7ad7a and work as expected: https://github.com/rust-lang/rust-clippy/pull/5088#issuecomment-582055695. I opened https://github.com/rust-lang/rust-central-station/pull/578~~ See https://github.com/rust-lang/rust-clippy/pull/5088#issuecomment-584581420
- [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
Fix run-pass tests when CARGO_TARGET_DIR is not set
r? @lzutao
I got
```
thread '[ui] ui/crashes/ice-1969.rs' panicked at 'failed to exec `"target/debug/test_build_base/crashes/ice-1969.stage-id"`: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/pkrones/.cargo/registry/src/github.com-1ecc6299db9ec823/compiletest_rs-0.4.0/src/runtest.rs:1350:25
```
on tests with `// run-pass` locally. The reason for this is, that I haven't set `CARGO_TARGET_DIR` and then `"target"` was used as the `CARGO_TARGET_DIR`. It seems, that `compiletest-rs` cannot deal with relative paths for `// run-pass` tests.
changelog: none
