Tracking issue: Gate bors on GH Actions instead of Travis

[jtgeibel]

This is a tracking issue for the proposal to gate bors on GH Actions instead of Travis.

Implementation:

• Change bors configuration

Open issues:

• panicked at 'Could not run jobs: NoMessageReceived' - Backtraces enabled in CI: Add docs to GH Actions workflow and add RUST_BACKTRACE=1 #2058 so we can begin to debug
• Caching behavior isn't always reliable
  • Some builds fail to get the cargo bin cache and have to compile diesel_cli in order to setup the database.
  • Unclear if we should be caching compilers at all, although it would be nice to avoid downloading compilers from upstream for every build. See docs added in CI: Add docs to GH Actions workflow and add RUST_BACKTRACE=1 #2058.
  • Many builds seem to recompile lots of dependencies, even though the cache of target/ was restored and Cargo.lock hasn't changed. [I think this was resolved in Correct actions syntax #2532]
• bors needs a single job to gate on. Currently on Travis, we ignore failures on the nightly channel. With our current end-success job on GH Actions, failures caused by a nightly regression will block us from merging any PRs.
• If a single job fails, GH only offers the ability to restart the entire workflow. When this happens, the old end-failure job remains in the UI with a red X, but it's not clear to me yet if that would cause bors to also fail a retry. Update: I haven't seen this in a while, this may be resolved.
• I've seen an occasional failure on the frontend with Error: Browser failed to connect within 30s. testem.js not loaded? See this build for an example. I don't recall ever seeing this occur on Travis. - timeout bumped to 120 seconds in ESLint: Use babel-eslint parser to allow decorators and field initialization #2158
• Over in Revert status badge to travis #2184 it appears that GH Actions may have issues displaying the correct build status badge, since master builds show up under auto because the builds are against the same commit hash. - Tracking issue: Gate bors on GH Actions instead of Travis #2059

Alternatives:

• Do nothing, we continue to gate bors on Travis instead of switching to GH Actions.

[Turbo87]

We currently have an issue with the GitHub Action for Rust nightly failing CI. In Travis we have set that job to be allowed to fail, but there does not seem to be a corresponding option in GitHub Actions.

I guess this makes the switch for bors from Travis to GitHub Actions a little more complicated 🤔

[jtgeibel]

I've updated the issue with a few other things I've seen and closed out things I think we've resolved.

In Travis we have set that job to be allowed to fail, but there does not seem to be a corresponding option in GitHub Actions.

I've included this above. If there were no other blockers, I'd say we could just drop nightly from Actions and keep running nightly on Travis. The big blocker I see at the moment is figuring out why caching still doesn't seem to be working optimally.

[Turbo87]

looks like rust-lang/homu#121 implemented the last missing piece, so I'll go ahead and close this as resolved :)