PHPCSStandards / PHP_CodeSniffer / 12046007088
78%
master: 79%

LAST BUILD BRANCH: feature/parse-error/File.getMethodProperties
DEFAULT BRANCH: master
Ran
Jobs 8
Files 262
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 76.256%. Remained the same
12046007088

push

github

jrfnl 
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 `concu... (continued)

18740 of 24575 relevant lines covered (76.26%)

75.33 hits per line

Jobs
ID Job ID Ran Files Coverage
1 cbf-os-ubuntu-latest-ubuntu-latest-php-8.1-custom-ini-true - 12046007088.1 262
1.08
 GitHub Action Run
2 cbf-os-ubuntu-latest-ubuntu-latest-php-7.2-custom-ini-false - 12046007088.2 262
0.18
 GitHub Action Run
3 os-ubuntu-latest-php-8.4-custom-ini-false - 12046007088.3 262
74.71
 GitHub Action Run
4 cbf-os-ubuntu-latest-ubuntu-latest-php-8.4-custom-ini-false - 12046007088.4 262
1.08
 GitHub Action Run
5 os-ubuntu-latest-php-7.2-custom-ini-false - 12046007088.5 262
72.54
 GitHub Action Run
6 os-windows-latest-php-7.2-custom-ini-false - 12046007088.6 262
1.97
 GitHub Action Run
7 os-ubuntu-latest-php-8.1-custom-ini-true - 12046007088.7 262
74.72
 GitHub Action Run
8 os-windows-latest-php-8.4-custom-ini-false - 12046007088.8 262
2.42
 GitHub Action Run
Source Files on build 12046007088