tiagobento opened a new pull request, #7084:
URL: https://github.com/apache/incubator-kie/pull/7084
## What changed
The three PR checks that also run on `main` — `CI :: Build`, `CI :: CI
Tests` and `Dev :: Tests` — now group pull request runs by PR number instead of
by `github.ref`:
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number ||
github.ref }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
```
Pushes to `main` keep `refs/heads/main` as their key, so a PR's runs and
`main`'s runs can no longer land in the same group. `pr-downstream.yml` already
keyed on the PR number. `docs/PR_CHECKS_AND_CI.md` states the resulting rules.
## Why
Every merge to `main` has been racing its own CI, and lately losing:
| Merge commit | Workflow | What happened |
| --- | --- | --- |
| ea3d9408c81 (#6845) | CI :: Build, CI :: CI Tests, Dev :: Tests | all
three push runs canceled within 2s of starting, no steps executed |
| 0415db7279f (#6888) | CI :: Build | push run canceled; for CI :: CI Tests
the PR's `closed` run lost the race instead |
The job annotations on the canceled runs read:
```
Canceling since a higher priority waiting request for CI ::
Build-refs/heads/main exists
```
These workflows subscribe to `pull_request` `types: [opened, synchronize,
reopened, closed]` so that closing a PR cancels its in-progress run through
`cancel-in-progress`; every job is guarded by `if: github.event.action !=
'closed'`, so the `closed` run itself does nothing. The concurrency group was
`${{ github.workflow }}-${{ github.ref }}`, and that is where it goes wrong.
GitHub's docs for the `pull_request` event: "If a pull request was closed as
a result of being merged, [`GITHUB_REF`] will be the fully qualified `ref` of
the branch it was merged into, for example `/refs/heads/main`." So on a merge,
the `closed` run is queued in `<workflow>-refs/heads/main`, the same group as
the push run for the merge commit, within the same second.
GitHub's docs on concurrency: "any existing `pending` job or workflow in the
same concurrency group will be canceled and the new queued job or workflow will
take its place." That applies to pending runs regardless of
`cancel-in-progress`, which only governs running ones. It is why the
`cancel-in-progress: ${{ github.event_name == 'pull_request' }}` guard from
#6862 was not enough for `CI :: Build`.
`Split Package Detection` does not subscribe to `closed` and has never been
canceled on `main`.
## Impact
- Push runs on `main` are no longer canceled by the merged PR's `closed` run.
- Closing or merging a PR now actually cancels its in-progress run. Before,
a merged PR's `closed` run sat in `main`'s group and the PR's own run kept
going.
- `CI :: CI Tests` and `Dev :: Tests` had `cancel-in-progress: true`
unconditionally, so two merges a few minutes apart could also cancel the older
`main` run. They now cancel only pull request runs, as `CI :: Build` already
did.
- No change to what any job does.
## Verification
The workflow YAML parses locally. The behaviour itself is only observable
after merging: the next merge to `main` should show the push run completing and
the PR's `closed` run skipped, with no cancellation on either.
References:
-
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request
-
https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
