Try GitHub Actions CI

[hugovk]

Same as #68 but made from a non-fork branch.

cc @cclauss.

[ghost]

DeepCode Report (#0078ac)

DeepCode analyzed this pull request.
There are no new issues.

[codecov]

Codecov Report

Merging #70 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #70   +/-   ##
=======================================
  Coverage   98.96%   98.96%           
=======================================
  Files           2        2           
  Lines         290      290           
=======================================
  Hits          287      287           
  Misses          3        3

Impacted Files	Coverage Δ
src/pypistats/__init__.py	99.03% <ø> (ø)	⬆️
src/pypistats/cli.py	98.79% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 65349de...0078ac8. Read the comment docs.

[hugovk]

Thanks again for the PRs, this is looking good. I've replicated what Azure Pipelines is doing, with the exception of uploading coverage to Codecov, and the sdist check. They can wait for later.

GitHub Actions looks very good. This is only using it as CI, and it's very like AP. Improvements:

• can include Python versions and OS in a matrix without creating templates and passing in parameters
• "You can run up to 20 jobs concurrently per repository across all workflows"! Compared to 10 with AP, 5 with Travis and 1 with AppVeyor.

---

https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events says of push:

Triggered on a push to a repository branch. Branch pushes and repository tag pushes also trigger webhook push events.

And pull_request:

Triggered when a pull request is assigned, unassigned, labeled, unlabeled, opened, edited, closed, reopened, synchronize, ready_for_review, locked, unlocked or when a pull request review is requested or removed.

What a lot of events!

https://help.github.com/en/articles/events-that-trigger-workflows#pull-request-events-for-forked-repositories says:

When you open a pull request from a forked repository, the pull request opens on the base repository by default. In this scenario, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository because the webhook configuration of the original base repository doesn't apply to forked repositories.

Does that mean pull_request is needed to trigger builds from forks? It continues:

If you intend to use the pull_request event to trigger CI tests, we recommend that you set up your workflow configuration to listen to the push event.

Is that saying to use both push and pull_request ? I guess so. Will send beta feedback.

It also means for each event, there's 2 builds. 2 × (3 OS × 2 Python tests + 1 OS × 1 Python lint) = 2 × 7 = 14.

Still within the 20 limit here, but AP doesn't double up.

---

Open questions

• How to trigger builds for PRs from forks?
• How to upload to Codecov? --> Maybe Support GitHub Actions codecov/codecov-node#118
• How not to trigger builds for PR labels etc?
• How not to double up builds?
• Does [CI skip] work? --> No, maybe the same weirdness as AP Use [ci skip] rather than ***NO_CI*** microsoft/azure-pipelines-agent#1270 (comment) or not supported?
• Cache pip downloads? --> Requested at https://git.luolix.topmunity/t5/GitHub-API-Development-and/Caching-files-between-GitHub-Action-executions/m-p/29445/thread-id/2609
• How does job cancelling work when another job fails?

[cclauss]

@chrispat Any comments or recommendations on this exploration?