[jp4a50]

The merge box only considers the newest run of a workflow for a commit. Runs for title and description edits skipped the build job, so since #8171 an edited PR's newest run had no internal-build check: the required check stayed expected, and the PR could not merge until its next push, even after its build passed. Before #8171 the skipped check counted as passing instead, which let #8034 merge while its build was still running.

No trigger or job condition can tell a base change from a title edit without leaving a skipped run behind, so run the build job for every edit. The internal build service (workerd-robot) reuses the existing edgeworker pipeline when the merge commit is unchanged, so an edit reports that pipeline's result rather than starting a new build. This needs workerd-robot to create a distinct instance per request (cloudflare/ew/workerd-robot!41); otherwise an edit's request collides with the push's and fails.

Restore the job id internal-build and a single concurrency group per PR, so an edit replaces a run in progress.

[clanky-the-clanker]

💬 Approved with comments — The workflow change does what it says: it restores the internal-build job id, uses one concurrency group per PR, and runs the build for every edit. One INFO note: edit runs only work once the build service creates a distinct instance per request, which the description already calls out.

Findings: 1 info (1 is an inline comment on the diff)

_{The decision is advisory: this review is a comment and never approves, blocks or requests changes on the pull request.}

---

📋 Code Quality: 💬 1 info

The change is consistent. Edit runs depend on the build service accepting a request that looks exactly like the push run's.

Recommendation: 💬 Optional Nits

• [INFO] Edit runs send the same request as the push run (run_id is github.run_attempt), so they work only once the build service creates a distinct instance per request. (.github/workflows/internal-build.yml:9)

View full review

• Every edited run now reaches tools/cross/internal_build.py. Its payload has pr_id, merge_commit_sha, head_commit_sha, run_id and branch_name, and run_id is ${{github.run_attempt}} (workflow line 130). That value is 1 on the first attempt of every new run, so a title-edit run sends the same payload as the push run before it. Edits only succeed once the build service creates a distinct instance per request, as the description says. If this merges first, edit runs fail internal-build and the PR stays blocked until its next push, which is the same symptom this change fixes. Merge after the service change is deployed.
• A single concurrency group with cancel-in-progress: true means an edit cancels the push run's job. The new run then reports the reused pipeline's result. internal_build.py does not cancel the internal pipeline when its job is cancelled, so the build itself keeps going.
• Restoring the internal-build job id and removing the conditional name brings back the plain required-check name.

---

✅ All other checks passed

📝 Documentation: ✅ LGTM

The updated workflow comments describe how the workflow behaves now.

---

_{Reviewed commit: 75033b3c}

[clanky-the-clanker]

ℹ️ INFO · Code Quality

Edit runs send the same request as the push run (run_id is github.run_attempt), so they work only once the build service creates a distinct instance per request.

Every edit now runs the build job. The request it sends (pr_id, merge SHA, head SHA, run_id = github.run_attempt, branch) is the same as the push run's, because run_attempt is 1 for each new run. Until the build service creates a distinct instance per request, edit runs fail internal-build and block the PR, so merge this only after that change is deployed. If the service accepts it, adding github.run_id to the request would make each run's request distinct on the workflow side.

[jp4a50]

Yes, that's what this MR is for: https://gitlab.cfdata.org/cloudflare/ew/workerd-robot/-/merge_requests/41