What happened
The required CI / test check is not triggered when a pull request is synchronized while targeting another branch and is then retargeted to main.
The CI workflow filters pull requests with branches: [main] but uses the default pull_request activity types. A base-branch change emits an edited event, while the default activity types are only opened, synchronize, and reopened.
PR #4161 demonstrated the gap:
- Its head was force-pushed while the base was still
fix/peer-mesh-cleanup.
- Six seconds later, the base was changed to
main.
- No automatic
CI run was created for that revision.
- A later force-push emitted
synchronize and immediately triggered the expected pull-request workflows.
Expected: retargeting an eligible pull request to main produces the required test check for the current revision.
How to reproduce
- Open a pull request targeting a branch other than
main.
- Push or force-push its head.
- Retarget the pull request to
main.
- Observe that no
CI / test run is created for the current pull request revision.
- Push or rebase the branch again.
- Observe that the resulting
synchronize event triggers CI.
Environment
Logs, screenshots, or additional context
The current workaround is to push or rebase the branch again after retargeting it.
A naive types: [opened, synchronize, reopened, edited] change would also start the workflow for unrelated title or body edits. With the current pull-request concurrency group, such an edit could cancel an in-progress valid run. The fix should therefore ensure that unrelated edits do not run, cancel, or satisfy the required check.
The existing CI / test check should remain the single authority; the fix should not introduce a parallel workflow or required check.
The later force-push triggered the expected run: https://github.com/apache/maka/actions/runs/33255615336
Filed with AI assistance (OpenAI Codex): the agent inspected the pull-request timeline, workflow configuration, and exact workflow runs; the human contributor reviewed this report before filing.
What happened
The required
CI / testcheck is not triggered when a pull request is synchronized while targeting another branch and is then retargeted tomain.The
CIworkflow filters pull requests withbranches: [main]but uses the defaultpull_requestactivity types. A base-branch change emits aneditedevent, while the default activity types are onlyopened,synchronize, andreopened.PR #4161 demonstrated the gap:
fix/peer-mesh-cleanup.main.CIrun was created for that revision.synchronizeand immediately triggered the expected pull-request workflows.Expected: retargeting an eligible pull request to
mainproduces the requiredtestcheck for the current revision.How to reproduce
main.main.CI / testrun is created for the current pull request revision.synchronizeevent triggersCI.Environment
apache/maka.github/workflows/ci.ymlon currentmainLogs, screenshots, or additional context
The current workaround is to push or rebase the branch again after retargeting it.
A naive
types: [opened, synchronize, reopened, edited]change would also start the workflow for unrelated title or body edits. With the current pull-request concurrency group, such an edit could cancel an in-progress valid run. The fix should therefore ensure that unrelated edits do not run, cancel, or satisfy the required check.The existing
CI / testcheck should remain the single authority; the fix should not introduce a parallel workflow or required check.The later force-push triggered the expected run: https://github.com/apache/maka/actions/runs/33255615336
Filed with AI assistance (OpenAI Codex): the agent inspected the pull-request timeline, workflow configuration, and exact workflow runs; the human contributor reviewed this report before filing.