Migrate to GitHub actions

[scasagrande]

Better late than never?

PR swaps the repo over to using Github actions instead of Travis. This should maintain the same test coverage, reporting, artifact uploading on releases, and pylint.

I did however turn off PR builds, and I will instead check the box for the repo settings that require branches to be up-to-date with the target in PRs. This has worked well for me in professional settings for repos that don't see multiple PR merges per day.

[trappitsch]

Should probably extend this to also run on pull-requests. In addition, could specify to only run on master, i.e., on a push to master or a PR request to master, something like this:

on:  
  push:
  pull_request:
    branches:
      - master

[scasagrande]

Yeah, mostly just been testing so far to see what works and doesn't

[trappitsch]

I had some issues with another project with github actions, namely that it also runs on forks. Now the {{ secrets.github_token }} won't be in that fork, and so the test will fail every time. You can limit that to only run if you are the owner, something like:

jobs:
  test:
    if: github.repository_owner == 'Galvant'
    runs-on: ubuntu-latest

Solution is taken from this discussion. Not sure if it's the most elegant one, but this way actions don't run and fail due to missing secrets on forks.

[scasagrande]

Oh interesting. That's a good idea for the coveralls stage.

[trappitsch]

Neat find

[scasagrande]

Yeah, I was getting a lot of issues with the official coveralls action integration here due to the structure of the report that pytest --cov= generates. Apparently the solution is to use the coverage command directly, but I want things to be symmetric with tox. The author here solved this problem.

[trappitsch]

Definitely a neat solution

[coveralls]

Coverage increased (+0.04%) to 99.404% when pulling f0c5c39 on migrate-to-github-actions into 4c3433a on master.

[scasagrande]

The one failing status check should just be a stale one from testing. Clicking the "Details" shows the correct information.

[trappitsch]

Does this include testing when a new pull request is started? I saw that you had pull requests and push in there in 9f1a61d, but now only push to any branch, so I'm wondering if the full test suite including coverage will run on a new pull request that is pushed from a fork.

I have in another project limited push testing to the main branch and added a test requirement for pull requests to main as:

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

[trappitsch]

Looks great, for fun I pushed this branch to my fork, github actions ran cleanly through, coverage didn't run at all.

[scasagrande]

@trappitsch perfect I was just about to ask you to do that!

I do want the coverage to function, so lets try to figure that out.

[scasagrande]

@trappitsch this should be your coveralls report from that build: https://coveralls.io/builds/45792067

[scasagrande]

@trappitsch can you open a fake PR from your fork targetting this branch, and we can see how the status checks look

[trappitsch]

Ah I see, the coverage is done in the task "finish". Here is this branch in my fork, you can see all actions pass:
https://github.com/trappitsch/InstrumentKit/tree/migrate-to-github-actions

I'll prep a fake PR from my fork to this branch, let's see what happens :)

[trappitsch]

Fake PR is #315

[trappitsch]

This might be related for the tests running twice:
https://github.community/t/how-to-trigger-an-action-on-push-or-pull-request-but-not-both/16662/3

There seem to be some solutions...

[scasagrande]

I've got a lot to learn here but I think this is better now. It should run on all PRs targetting any branch, and then run post-merge on the default branch.

[trappitsch]

The commit message is indeed long and weird, but seems only for that one...
Otherwise this looks great!

[scasagrande]

🚢