fix(ci): prevent edited events from creating skipped CI runs#13170
fix(ci): prevent edited events from creating skipped CI runs#13170
Conversation
- Create new workflow that triggers when PR base branch is edited - Remove `edited` trigger from main CI workflow to avoid duplicate runs - Simplify CI workflow conditions by removing base change check
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
GeorgeDong32
left a comment
GeorgeDong32
left a comment
There was a problem hiding this comment.
LGTM with one minor suggestion:
Suggested improvement: Consider adding status: 'completed' to the listWorkflowRuns API call to avoid re-running in-progress workflows:
const runs = await github.rest.actions.listWorkflowRuns({
workflow_id: 'ci.yml',
head_sha: context.payload.pull_request.head.sha,
per_page: 1,
status: 'completed', // Only get completed runs
});This ensures the re-run only targets completed CI runs, preventing potential race conditions if the CI is still running when the base branch is changed.
Otherwise, the PR looks great - clean separation of concerns and proper use of the GitHub Actions API.
DeJeune
left a comment
DeJeune
left a comment
There was a problem hiding this comment.
Well-designed fix with clean separation of concerns. Splitting the edited event into its own lightweight workflow solves the "skipped run hiding real CI results" problem elegantly — different workflow names never interfere with each other in the GitHub UI.
Significant:
reRunWorkflowAPI returns 409 if the target run is still in-progress/queued. Consider adding a status check or try/catch to handle this gracefully.
Nit:
- Top-level
permissionscould be scoped to job-level for precision (minor, single-job workflow).
Positives:
- Clean architectural split that avoids masking real CI status
- Simplified
ifconditions inci.yml— much more readable - Excellent PR description with clear tradeoff analysis
| per_page: 1, | ||
| }); | ||
| if (runs.data.workflow_runs.length > 0) { | ||
| await github.rest.actions.reRunWorkflow({ |
There was a problem hiding this comment.
Significant: reRunWorkflow will fail if the previous run is still in_progress or queued (API returns 409 Conflict). This can happen if someone changes the base branch while CI is still running from a recent push.
Consider either:
- Checking the run's
statusbefore re-running and cancelling it first if needed - Wrapping in a try/catch with a helpful log message so it doesn't show as a workflow failure
const run = runs.data.workflow_runs[0];
if (run.status === 'completed') {
await github.rest.actions.reRunWorkflow({...});
} else {
console.log(`CI run ${run.id} is still ${run.status}, skipping re-run`);
}| name: Re-run CI on base branch change | ||
|
|
||
| permissions: |
There was a problem hiding this comment.
Nit: Top-level permissions here grants actions: write to the entire workflow. This is fine for now since there's only one job, but worth noting that any future jobs added to this file would inherit this permission. A job-level permissions block would be more precise.
Address review feedback: only re-run completed CI runs to avoid 409 conflicts, and move permissions to job level for better scoping. Co-Authored-By: Claude Opus 4.6 <[email protected]>
3 participants
What this PR does
Before this PR:
Editing a PR's title or body triggers the
editedevent in the CI workflow. Although job-levelifconditions skip execution, GitHub still creates a new workflow run with "skipped" status. Since GitHub UI shows the latest run, this hides the real CI results from the previousopened/synchronizerun.After this PR:
editedfrom CI workflow trigger types, so title/body edits no longer create skipped CI runsci-rerun-on-base-change.yml) that listens foreditedevents and re-runs the latest CI run only when the PR's base branch is changedFixes #13150 (follow-up)
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
editedwithout a re-run workflow — would lose CI re-trigger on base branch changes, which was a known issue before fix(ci): skip CI on PR body/title edits, only re-run on base branch changes #13150editedwith job-levelif— the current approach that causes the problem we're fixingBreaking changes
None
Special notes for your reviewer
actions/github-scriptto callreRunWorkflowAPI, which re-runs the existing CI run in-place rather than creating a new oneactions: writepermission to trigger re-runsbrancheslist in the new workflow mirrors the main CI workflow to stay in syncChecklist
Release note