Use GitHub actions for CI

[therealprof]

Signed-off-by: Daniel Egger daniel@eggers-club.de

[rust-highfive]

r? @Emilgardis

(rust_highfive has picked a reviewer for you, use r? to override)

[therealprof]

@rust-embedded/tools This is ready now. For now this only adds GitHub Actions as the missing second factor on all PRs. It's not only much faster than Travis but also not taking up any shared resources. And there's still room for optimisation.

Ultimately I'd like to get rid of Travis altogether but that's up for a separate PR/discussion.

[Emilgardis]

Great! I don't have much experience with GH actions so would be good to get another pair of eyes on this.

LGTM

[therealprof]

We discussed the details quite a bit on the matrix channel. Probably the most GHA experienced person in the team is @adamgreig.

[adamgreig]

Generally LGTM, thanks for doing this!

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

I'm not sure about this. I think your intent is to stop GHA building the commit in a PR and then immediately building again once it's merged to master, but I think what actually happens here is only pushes to the master branch (including merging a PR) and only PRs targeting the master branch (most but not all PRs) will get CI. However that means PRs to non-master branches get no CI which doesn't seem desirable. Additionally, we use bors in svd2rust, which requires that CI runs on staging and trying branch pushes, so at the minimum those should be in here. None of this is really all that well documented and I know GHA does various clever things for you (including automatically testing merge commits instead of the PR tip), but I don't know exactly which clever things. I'd suggest for now we try:

on:
  push:
    branches: [ staging, trying, master ]
  pull_request:

And if we then find this does too many builds, look in to reducing them. We could also remove pull_request: to only trigger builds on bors try rather than automatically on all PRs.

I noticed we also use Travis to build release binaries which are uploaded to GitHub releases; we should also do this in GHA before removing Travis entirely.

We'll also want to update both bors and the repo branch protection settings to use GHA; perhaps this PR should also update bors.toml to check against GHA status instead of Travis status.

[therealprof]

(most but not all PRs)

Can we even handle those? I think bors will report an error if you attempt to do a PR not aimed at master.

I'd prefer to do this step by step. For now the important thing is to get regular (and reasonably fast) CI for PRs up and running again and then we expand into other directions.

[therealprof]

I think your intent is to stop GHA building the commit in a PR and then immediately building again once it's merged to master

No, if you do pull + pr it will always build PRs twice which is very wasteful, cf. the first run on the PR above: All checks have passed 41 successful checks
vs the last one: All checks have passed 22 successful checks

[adamgreig]

I'd prefer to do this step by step. For now the important thing is to get regular (and reasonably fast) CI for PRs up and running again and then we expand into other directions.

That's fair; I still think we require CI builds on staging and trying branches in that case.

No, if you do pull + pr it will always build PRs twice which is very wasteful

I don't understand what you mean by "pull + pr". What's causing the double build on that commit? Is it because you pushed to a branch on the repository (triggering branch push) and because that branch is a PR? I think my suggested config would also solve this in that case, while still allowing PRs not aimed as master and allowing bors to work:

on:
  push:
    branches: [ staging, trying, master ]
  pull_request:

[therealprof]

I don't understand what you mean by "pull + pr". What's causing the double build on that commit? Is it because you pushed to a branch on the repository (triggering branch push) and because that branch is a PR? I think my suggested config would also solve this in that case, while still allowing PRs not aimed as master and allowing bors to work:

Sorry, I meant "push" and "pull_request". If you do both without specifing a branch filter it will trigger twice.

I'm not quite sure how that works but we can try your approach.

[therealprof]

@adamgreig Can I get a r+ now? ;)

[adamgreig]

Yep, let's give this a go!

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push