From f8ed72b9768797c7db92db0f002a64d65b6478d8 Mon Sep 17 00:00:00 2001
From: jrfnl <jrfnl@users.noreply.github.com>
Date: Wed, 27 Nov 2024 08:00:21 +0100
Subject: [PATCH] GH Actions/test: allow concurrency for code coverage builds -
 take two

Follow up on 710, which was added with the following reasoning:

> The `concurrency` setting will cancel running workflows if a new push to the same branch is seen. This is useful to prevent unnecessary workflow runs (as the previous push was superseded, so the outcome is no longer relevant).
>
> However, for the "main" branches (`master` and `4.0`), this workflow cancelling means that if multiple PRs are merged in succession, only the code coverage for the _last_ merge is recorded in Coveralls as the workflow runs on `master` for the previous merges will have been cancelled.
>
> While in practice, it's not a biggie, it does make it more difficult to identify which commit/merge added or decreased code coverage.

Let's try this again.

The previous attempt to prevent cancelling code coverage builds for merges to the "main" branches is not working as intended and is still cancelling builds.

This is likely due to the way GH looks at concurrency groups:
> By default, GitHub Actions allows multiple jobs within the same workflow, multiple workflow runs within the same repository, and multiple workflow runs across a repository owner's account to run concurrently. This means that multiple workflow runs, jobs, or steps can run at the same time.
>
> You can use `*.concurrency` to ensure that only a single job or workflow using the same concurrency group will run at a time.
>
> This means that there can be at most one running and one pending job in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be `pending`. Any existing `pending` job or workflow in the same concurrency group, if it exists, will be canceled and the new queued job or workflow will take its place.

Interpreting this strictly, this appears to mean that, as soon as a `concurrency` `group` name is defined, there can now only be - at most - two builds for that group - one running, one queued -, while without the `concurrency` `group` name being associated with a build, there can be unlimited concurrent builds.

This means that code coverage builds for merges in quick succession are still being killed off.

This new attempt now moves the `concurrency` setting from the workflow level to the "job" level and adds the `job` name to the `group` key.
This should hopefully still allow for cancelling in progress builds for the `build` and `test` jobs, while leaving the `coverage` (and `coveralls-finish`) jobs alone.

The down-side of this change (providing it works) is that it can't be limited to the "main" branches, which means that the `coverage` jobs will now continue running for _every_ push to an open pull request as well.
While a little wasteful, that appears to be the price to pay.

Refs:
* https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs
---
 .github/workflows/test.yml | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index d295e91204..212798b30f 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -14,16 +14,14 @@ on:
   # Allow manually triggering the workflow.
   workflow_dispatch:
 
-# Cancels all previous workflow runs for the same branch that have not yet completed,
-# but don't cancel when it's one of the "main" branches as that prevents
-# accurate monitoring of code coverage.
-concurrency:
-  # The concurrency group contains the workflow name and the branch name.
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: ${{ github.ref_name != 'master' && github.ref_name != '4.0' }}
-
 jobs:
   build:
+    # Cancels all previous runs of this particular job for the same branch that have not yet completed.
+    concurrency:
+      # The concurrency group contains the workflow name, job name and the branch name.
+      group: ${{ github.workflow }}-${{ github.job }}-${{ github.ref }}
+      cancel-in-progress: true
+
     runs-on: ubuntu-latest
     name: "Build Phar on PHP: 8.0"
 
@@ -82,6 +80,12 @@ jobs:
         run: php phpcbf.phar ./scripts
 
   test:
+    # Cancels all previous runs of this particular job for the same branch that have not yet completed.
+    concurrency:
+      # The concurrency group contains the workflow name, job name, job index and the branch name.
+      group: ${{ github.workflow }}-${{ github.job }}-${{ strategy.job-index }}-${{ github.ref }}
+      cancel-in-progress: true
+
     runs-on: ubuntu-latest
     needs: build
 
@@ -215,6 +219,8 @@ jobs:
         run: php phpcs.phar
 
   coverage:
+    # Explicitly *NOT* setting "concurrency" for this job to allow for monitoring code coverage for all merges.
+
     runs-on: ${{ matrix.os }}
 
     strategy:
@@ -256,8 +262,8 @@ jobs:
         shell: bash
         run: |
           # Set the "short_open_tag" ini to make sure specific conditions are tested.
-          if [[ ${{ matrix.custom_ini }} == true && "${{ matrix.php }}" == '7.2' ]]; then
-            echo 'PHP_INI=, date.timezone=Australia/Sydney, short_open_tag=On' >> "$GITHUB_OUTPUT"
+          if [[ ${{ matrix.custom_ini }} == true && "${{ matrix.php }}" == '7.2' ]]; then
+            echo 'PHP_INI=, date.timezone=Australia/Sydney, short_open_tag=On' >> "$GITHUB_OUTPUT"
           fi
 
       - name: Install PHP