[PR #45] [MERGED] fix(bump-callers): commit all of a repo's files onto one bump branch (BE-3896) #54

New issue

Closed

opened 2026-10-26 22:35:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 22:35:46 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/github-workflows/pull/45
Author: @mattmillerai
Created: 7/21/2026
Status: ✅ Merged
Merged: 7/21/2026
Merged by: @mattmillerai

Base: matt/be-3882-stable-bump-branch ← Head: matt/be-3896-multi-file-per-repo

📝 Commits (2)

4455be2 fix(bump-callers): commit all of a repo's files onto one bump branch (BE-3896)
214a1a7 fix(bump-callers): harden per-file staging against partial/erroneous bumps (BE-3896)

📊 Changes

2 files changed (+317 additions, -60 deletions)

View changed files

📝 .github/bump-callers/bump-callers.sh (+166 -58)
📝 .github/bump-callers/tests/test_bump_callers.sh (+151 -2)

📄 Description

STACKED — merging lands on matt/be-3882-stable-bump-branch (owned by mattmillerai), NOT main. This PR is stacked on the still-open #44 (BE-3882), which is where bump-callers.sh and its shared-stable-branch flow live; they are not on main yet. GitHub will auto-retarget this PR to main once #44 merges. Do not treat this as safe-to-merge onto main on its own.

ELI-5

The SHA-bumper opens one PR per repo on a fixed branch (ci/bump-<tag>). To keep that PR a clean "bump to @SHORT" diff, it wipes the branch back to the repo's default-branch tip before committing. That wipe ran once per file. So when one repo pins the reusable workflow from two files (a monorepo), the second file's wipe erased the first file's commit — the PR ended up with only the last file bumped, even though every file "succeeded." This groups the work by repo: wipe the branch once, then commit each of that repo's files onto it, then open/update the single PR. Now both files ride along.

What changed

bump-callers.sh: bump_one() (per-entry) → bump_repo() (per-repo). The driving loop now groups the flat repo|file|label entry list by repo (first-seen order preserved) and calls bump_repo once per repo with all its entries.
- Pass 1 stages every file that actually needs a bump (fetch blob + SHA, skip missing/already-pinned) without writing anything — so a repo whose files are all missing/already-pinned still resets no branch and opens no PR (unchanged skip behavior).
- If ≥1 file is staged: read the default-branch tip and reset the stable branch once, then Pass 2 commits each staged file with a successive PUT carrying that file's own blob SHA. The files are distinct paths, so committing one never changes another's blob — every PUT applies cleanly and the branch accumulates all of them.
- PR labels: apply every distinct non-empty label the repo's entries carried (deduped).
tests/test_bump_callers.sh: the gh stub now models the one bump branch's committed file set (a git/refs create/reset truncates it; a contents PUT appends the file). A new monorepo case drives two entries for the SAME repo and asserts both files land on the branch and exactly one PR is opened.

Only triggers on the multi-file path

Single-file-per-repo callers are structurally unchanged — the 37 pre-existing test assertions (single caller, PR reuse, decoy-fork rejection, two distinct repos, empty/malformed handling) all pass untouched.

Testing

bash .github/bump-callers/tests/test_bump_callers.sh → 45 passed, 0 failed (37 existing + 8 new).
shellcheck -x .github/bump-callers/bump-callers.sh .github/bump-callers/tests/test_bump_callers.sh → clean.
Regression proof: ran the new test against the pre-fix script — the monorepo case's "first file present on the branch" / "branch holds exactly two files" / "opened exactly ONE PR" assertions fail (only the last file ci-b survives, two PRs opened), exactly matching the bug. Against this fix they pass.

Deferred from a review thread on #44 (BE-3896).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/github-workflows/pull/45 **Author:** [@mattmillerai](https://github.com/mattmillerai) **Created:** 7/21/2026 **Status:** ✅ Merged **Merged:** 7/21/2026 **Merged by:** [@mattmillerai](https://github.com/mattmillerai) **Base:** `matt/be-3882-stable-bump-branch` ← **Head:** `matt/be-3896-multi-file-per-repo` --- ### 📝 Commits (2) - [`4455be2`](https://github.com/Comfy-Org/github-workflows/commit/4455be201228c4fb017bbfa4e55f8816b6dca5a5) fix(bump-callers): commit all of a repo's files onto one bump branch (BE-3896) - [`214a1a7`](https://github.com/Comfy-Org/github-workflows/commit/214a1a7bd843fd97848495cd31c4c8c1fe95d722) fix(bump-callers): harden per-file staging against partial/erroneous bumps (BE-3896) ### 📊 Changes **2 files changed** (+317 additions, -60 deletions) <details> <summary>View changed files</summary> 📝 `.github/bump-callers/bump-callers.sh` (+166 -58) 📝 `.github/bump-callers/tests/test_bump_callers.sh` (+151 -2) </details> ### 📄 Description > **STACKED — merging lands on `matt/be-3882-stable-bump-branch` (owned by mattmillerai), NOT `main`.** This PR is stacked on the still-open #44 (BE-3882), which is where `bump-callers.sh` and its shared-stable-branch flow live; they are not on `main` yet. GitHub will auto-retarget this PR to `main` once #44 merges. Do **not** treat this as safe-to-merge onto `main` on its own. ## ELI-5 The SHA-bumper opens one PR per repo on a fixed branch (`ci/bump-<tag>`). To keep that PR a clean "bump to @SHORT" diff, it wipes the branch back to the repo's default-branch tip before committing. That wipe ran **once per file**. So when one repo pins the reusable workflow from **two** files (a monorepo), the second file's wipe erased the first file's commit — the PR ended up with only the *last* file bumped, even though every file "succeeded." This groups the work by repo: wipe the branch **once**, then commit **each** of that repo's files onto it, then open/update the single PR. Now both files ride along. ## What changed - `bump-callers.sh`: `bump_one()` (per-entry) → `bump_repo()` (per-repo). The driving loop now groups the flat `repo|file|label` entry list by repo (first-seen order preserved) and calls `bump_repo` once per repo with all its entries. - **Pass 1** stages every file that actually needs a bump (fetch blob + SHA, skip missing/already-pinned) **without writing anything** — so a repo whose files are all missing/already-pinned still resets no branch and opens no PR (unchanged skip behavior). - If ≥1 file is staged: read the default-branch tip and reset the stable branch **once**, then **Pass 2** commits each staged file with a successive PUT carrying **that file's own blob SHA**. The files are distinct paths, so committing one never changes another's blob — every PUT applies cleanly and the branch accumulates all of them. - PR labels: apply every distinct non-empty label the repo's entries carried (deduped). - `tests/test_bump_callers.sh`: the `gh` stub now models the one bump branch's committed file set (a `git/refs` create/reset **truncates** it; a contents PUT **appends** the file). A new **monorepo** case drives two entries for the SAME repo and asserts **both** files land on the branch and exactly **one** PR is opened. ## Only triggers on the multi-file path Single-file-per-repo callers are structurally unchanged — the 37 pre-existing test assertions (single caller, PR reuse, decoy-fork rejection, two *distinct* repos, empty/malformed handling) all pass untouched. ## Testing - `bash .github/bump-callers/tests/test_bump_callers.sh` → **45 passed, 0 failed** (37 existing + 8 new). - `shellcheck -x .github/bump-callers/bump-callers.sh .github/bump-callers/tests/test_bump_callers.sh` → clean. - **Regression proof:** ran the new test against the pre-fix script — the monorepo case's "first file present on the branch" / "branch holds exactly two files" / "opened exactly ONE PR" assertions **fail** (only the last file `ci-b` survives, two PRs opened), exactly matching the bug. Against this fix they pass. Deferred from a review thread on #44 (BE-3896). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-26 22:35:46 +00:00