ci: Limit concurrent workflow jobs to one per workflow per branch

[matthewfeickert]

Description

Resolves #1631

Use GitHub Actions concurrency key with cancel-in-progress option to limit the number of concurrent workflow jobs to one per workflow per github.head_ref github.ref (so per branch which results in per PR). This should speed up CI by keeping the queue clear by canceling CI jobs when another commit has been pushed that would kick off the same workflow.

Example:

• On a PR a commit is pushed that doesn't pass the pre-commit checks.
• pre-commit.ci pushes back the changes that allows for pre-commit to pass.
• There would now be two jobs running for all the GHA workflows that run per PR, which is wasteful and slows things down.
• With

concurrency:
  group: some-identifying-string-${{ github.ref }}
  cancel-in-progress: true

the offending first workflow job is canceled and the second workflow job from pre-commit.ci's push can start.

Checklist Before Requesting Reviewer

• Tests are passing
• "WIP" removed from the title of the pull request
• Selected an Assignee for the PR to be responsible for the log summary

Before Merging

For the PR Assignees:

• Summarize commit messages into a comprehensive review of the PR

* Add concurrency groups to all workflows that run on PRs
   - Use 'cancel-in-progress' option to cancel already running workflow jobs
   - This should speed up CI by keeping the queue clear by canceling CI jobs
      when another commit has been pushed that would kick off the same
      workflow
   - https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#concurrency

[matthewfeickert]

I rebased off of master for this PR and the already running jobs got canceled as expected. 👍

[codecov]

Codecov Report

Merging #1632 (a074d8a) into master (f94e72f) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1632   +/-   ##
=======================================
  Coverage   98.12%   98.12%           
=======================================
  Files          64       64           
  Lines        4270     4270           
  Branches      683      683           
=======================================
  Hits         4190     4190           
  Misses         46       46           
  Partials       34       34           

Flag	Coverage Δ
contrib	26.25% <ø> (ø)
doctest	60.58% <ø> (ø)
unittests	96.18% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

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 f94e72f...a074d8a. Read the comment docs.

[matthewfeickert]

Oh. I just realized this might be problematic for our release workflow as the tag workflow executes and pushes to master very quickly after we merge a release triggering PR.

Example:

commit 248e40072ca933813214ada3fd79b10633ffef1d (tag: v0.6.3)
Author: GitHub Action <[email protected]>
Date:   Fri Sep 3 18:53:29 2021 +0000

    Bump version: 0.6.2 → 0.6.3
    
    Triggered by #1583 via GitHub Actions.

commit 5a56b28f59ec0518b42116c422583c48267a6745
Author: Matthew Feickert <[email protected]>
Date:   Fri Sep 3 13:53:09 2021 -0500

    docs: Add v0.6.3 release notes (#1583)
    
    * Add release notes for pyhf v0.6.3
       - c.f. https://github.com/scikit-hep/pyhf/releases/tag/v0.6.3
    * Update link to uproot in README to point to uproot4 GitHub repo
    * Add Sviatoslav Sydorenko as a contributor

for v0.6.3 the tag workflow push with tag v0.6.3 happened just 20 seconds (note +0000 vs. -0500) after we merged the release triggering PR.

As

github.head_ref: The head_ref or source branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target.

does that mean that on push_events to master

concurrency:
  group: ci-${{ github.head_ref }}
  cancel-in-progress: true

will evaluate the group to ci? Or does concurrency not exist for push_events?

[kratsg]

does that mean that on push_events to master

concurrency:
  group: ci-${{ github.head_ref }}
  cancel-in-progress: true

will evaluate the group to ci? Or does concurrency not exist for push_events?

isn't the head_ref for a tag the tag name, rather than the branch?

[matthewfeickert]

isn't the head_ref for a tag the tag name, rather than the branch?

Apparently not, as the github context docs say that

github.head_ref: The head_ref or source branch of the pull request in a workflow run. This property is only available when the event that triggers a workflow run is either pull_request or pull_request_target.

github.ref: The branch or tag ref that triggered the workflow run. For branches this is the format refs/heads/<branch_name>, and for tags it is refs/tags/<tag_name>.