chore: rename release branch main->release in-repo (w1-w4)#1027
Open
joeharris76 wants to merge 3 commits into
Open
chore: rename release branch main->release in-repo (w1-w4)#1027joeharris76 wants to merge 3 commits into
joeharris76 wants to merge 3 commits into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9aff33d43a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
1 task
joeharris76
added a commit
that referenced
this pull request
Jul 7, 2026
Creates _project/TODO/main/active/human-action-required.yaml — a single running index of actions only the human maintainer can perform (GitHub repo-admin changes, Code-Owner reviews, human recruitment), which agents in this project cannot do (the sandbox git remote rejects branch/default-branch changes, admin APIs are out of scope, CODEOWNERS review must be human). Seeded with the current queue: - w1: Code-Owner review + merge PR #1027 (in-repo main->release rename). - w2 (needs w1): GitHub-side branch rename main->release + ruleset recreate. - w3: set default_branch=develop (+ verify scheduled workflows) — also activates the §2.8 workflow_run companion and the release-canary cron. - w4: recruit one external contributor for the Phase-2 submission dry-run. - w5 (optional): delete the 5 dead orphan branches (agent couldn't; harmless — they're allowlisted for the orphaned-commit detector). Each work unit cross-references its authoritative source TODO and gives the exact command. New maintainer/human actions get appended here so there is one place to see what's waiting on the maintainer. todo validate + check-graph green. Claude-Session: https://claude.ai/code/session_01JFdZAbavgrKaNLe4YZa3zf Co-authored-by: Claude <noreply@anthropic.com>
joeharris76
added a commit
that referenced
this pull request
Jul 10, 2026
…ut (#1089) main and develop have unrelated roots (Phase 4 filter-merge) and diverge permanently: main carries one squash commit per release that develop never sees, and the 2026-04-27 amendment removed A4 step 6 (rebase develop onto main). A vX.Y.Z branch cut cleanly from develop is therefore not mergeable into main -- GitHub cannot compute a merge ref, so the release PR sits at CONFLICTING and *no CI runs at all*: neither validate-base nor release-required-result ever trigger. Every cut before v0.3.1 (#711, #712, #1029, #1043, #1072) worked around this by hand. release-cut now performs the merge itself, between the "Release vX.Y.Z" commit and the push. -s ours records origin/main as a second parent while preserving the curated release tree byte-for-byte; release-finalize's squash-merge then collapses the branch to a single commit, so the merge never reaches main's release-only ledger. Verified: after the merge, merge-base(origin/main, HEAD) == origin/main, so GitHub's three-dot PR diff is exactly the release delta. The recipe guards the merge by asserting the tree hash is unchanged across it. A -s ours merge cannot change the tree by construction, so the guard is really an assertion that the strategy is still ours -- any other strategy drags main-only content back into the curated tree, silently un-curating the release. The guard is also a no-op-safe check: if origin/main is already an ancestor, git reports "Already up to date", the tree is unchanged, and the cut proceeds. --no-verify: git merge fires pre-merge-commit (not pre-commit). That hook is not in default_install_hook_types today, so this is defensive -- but curation has already deleted .pre-commit-config.yaml and the repo:local hook entrypoints by this point, so installing it later would otherwise break every cut here. Ordering is load-bearing: the merge must follow generate_changelog_entry.py --since-ref origin/main, which needs main to still be a non-ancestor, and must precede the push, or the PR is born CONFLICTING again. The new regression test pins all three positions plus the strategy flags. Coordination with #1027 (rename main -> release): this change uses the literal origin/main spelling that the rest of the Makefile already uses, so that PR's textual rename sweep picks these lines up with the existing ones. Expect a mechanical conflict in the release-cut header comment (step renumbering). Co-authored-by: Joe Harris <57046+joeharris76@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Decision B of the branching-strategy review: `main` is already the release-only branch (validate-*-pr.yml rejects non-vX.Y.Z heads, release-finalize fast-forwards+tags it). `release` is the accurate name. This lands the IN-REPO half only (work units w1-w4); the GitHub-side branch rename + ruleset recreation (w5/w6) are maintainer-only admin actions, left pending per docs/operations/branch-rename-runbook.md. - w1 workflows: lint/test/perf-smoke/docs/results-explorer-browser triggers main->release; docs.yml Pages deploy gate refs/heads/main-> release; release.yml verify-tag-on-main->verify-tag-on-release (job, origin/release ancestor checks) — the tag-shaped-ref PyPI publish condition is untouched; test.yml's six base_ref=='main'/!='main' release-gating conditionals->release; validate-main-pr.yml renamed to validate-release-pr.yml (+ internal strings, RELEASE_CANARY_BRANCH). - w2 Makefile: release-cut/release-finalize base branch, checkout/pull, --since-ref origin/release, ruleset-name text, help text, and the develop|main branch-protection guards. MAIN_CLONE / "main clone" worktree-pool concept left untouched (unrelated to the branch name). - w3 docs/templates: release-guide.md, RELEASE_PR_TEMPLATE.md, CONTRIBUTING.md, repo-admin-settings.md (release-identity refs only; the default-branch-scheduling section left as-is with a caveat note), results-phase-2-runbook.md; landing/index.html footer blob/main-> blob/release; blog blob/main links pinned to release tags (v0.1.4, v0.2.1) verified with git cat-file. - w4 new docs/operations/branch-rename-runbook.md: ordered migration, no-real-gap reasoning, verification, rollback, PyPI/Pages branch- independence. Verification: all workflows parse; grep for refs/heads/main in workflows and --base main in Makefile both empty; tests/unit/test_release_ infrastructure.py 38 passed; todo validate + check-graph green. Item stays In Progress (w5/w6 admin pending). release.yml is touched so this PR is CODEOWNERS-gated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFdZAbavgrKaNLe4YZa3zf
…heck's hardcoded old name Two review findings on the main->release in-repo rename: - validate-release-pr.yml set RELEASE_CANARY_BRANCH=release, but release-canary.yml's scheduled runs report the branch they were TRIGGERED from (the repository default, which this migration moves to develop), not RELEASE_CANARY_REF's checkout target. Left as "release", every release PR's validate-base would fail to find any canary runs. Changed to "develop", matching RELEASE_CANARY_REF/ RELEASE_CANARY_CHECKED_REF already in the same env block. - scripts/ruleset_drift_check.py's parse_expected_rulesets still hardcoded the old "main-release-only" name, but the runbook renamed the section to "release-only". Reproduced the exact crash this would cause (ValueError: could not find ruleset section for 'main-release-only') via git stash before fixing. Updated the two test files that keyed off the old name to match. Verified via git stash that all touched tests fail without these fixes.
The w1-w4 rename moved validate-main-pr.yml -> validate-release-pr.yml but left four comment/docstring pointers at the old path, plus origin/main as the --since-ref example now that release-cut passes origin/release. repo-admin-settings.md's pointer arrived from develop after this branch was cut, in a hunk this branch never touched, so the rebase merged it without a conflict. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
joeharris76
force-pushed
the
chore/rename-main-to-release-in-repo
branch
from
8f45fb5 to
8522021
Compare
joeharris76
added a commit
that referenced
this pull request
Jul 10, 2026
* fix(ci): retarget seed-corpus PR from main to develop `seed-corpus.yml` opened its automated bundle PR with `--base main`. That was already broken: the head it pushes is `chore/seed-corpus-<date>-<run>`, and `validate-main-pr.yml` rejects any PR into `main` whose head is not a `vX.Y.Z` release branch. It would also hard-fail outright once the main -> release rename (PR #1027) removes the `main` branch. `develop` is the intended base: `sync-results-data-to-published.yml` triggers on pushes to `develop` under `results-data/bundles/**` and documents "a maintainer-run seed corpus refresh from `seed-corpus.yml`" as its motivating case. Correct the PR body's "Merging" section to match that flow -- it claimed the merge triggers `docs`, which only fires on pushes to the release branch. The workflow is `workflow_dispatch`-only and `release-cut` curates it out of the release tree, so no CI job covers this. Add unit tests pinning the base to `develop` and encoding why a `chore/` head can never target the release branch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(ci): unescape backticks in seed-corpus PR body The body is built with a quoted heredoc (`<<'EOF'`), so the shell performs no expansion inside it. The `\`` escapes were therefore not protecting anything -- they rendered as literal backslashes in the PR body. Drop them and add a guard test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Joe Harris <57046+joeharris76@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Decision B of the branching-strategy review (
rename-release-branch-main-to-release).mainis already the release-only branch —validate-*-pr.ymlrejects any PR whose head is not avX.Y.Zbranch,release-finalizefast-forwards + tags it, and its HEAD is always the exact latest-release commit.releaseis the accurate name.This PR lands the IN-REPO half only (work units w1-w4). The GitHub-side branch rename and ruleset recreation (w5/w6) are maintainer-only GitHub admin actions and are NOT performed here — no GitHub admin/settings change was made in this session. The TODO item stays In Progress with w5/w6 pending. The full ordered migration is documented in the new
docs/operations/branch-rename-runbook.md.What changed
main→releasetriggers inlint.yml,test.yml,perf-smoke.yml,docs.yml(incl. the Pages deploy gaterefs/heads/main→refs/heads/release),results-explorer-browser.yml. Functional/careful paths:release.yml'sverify-tag-on-mainjob renamed toverify-tag-on-release(job name,needs:refs,git fetch origin release, allorigin/releaseancestor checks) — the tag-shaped-ref PyPI publish conditionstartsWith(github.ref, 'refs/tags/v')is untouched;test.yml's sixbase_ref == 'main'/!= 'main'release-gating conditionals (compat-test, integration-smoke, integration, correctness-gate, release-readiness, release-required-result) →'release'(the!= 'develop'checks left asdevelop);validate-main-pr.ymlrenamed tovalidate-release-pr.yml(+ internal strings,RELEASE_CANARY_BRANCH).release-cut/release-finalizebase branch (--base main→--base release), checkout/pull,generate_changelog_entry --since-ref origin/main→origin/release, ruleset-name text, help text, and thedevelop|mainbranch-protection guards.MAIN_CLONE/ "main clone" worktree-pool concept left untouched (unrelated to the branch name).release-guide.md,RELEASE_PR_TEMPLATE.md,CONTRIBUTING.md,repo-admin-settings.md(release-identity refs only — the default-branch-scheduling section is left as-is with an added caveat note, since scheduled-workflow behavior tracks the default branch, which Decision A changes separately),results-phase-2-runbook.md(explorer Pages-deploy gate refs).landing/index.htmlfooterblob/main→blob/release. Blogblob/mainlinks pinned to the matching release tags (duckdb-tpch →v0.1.4; the two v0.2.1 posts →v0.2.1), each verified withgit cat-file -e <tag>:<path>.docs/operations/branch-rename-runbook.md. Ordered migration (Decision A default-switch → this PR → Decision B admin rename), the no-real-gap reasoning, verification, rollback, and the verified-safe notes (PyPI trusted publishing and GitHub Pages are branch-independent).Ordering caveat (maintainer, please sequence w5/w6 right after merge)
Merging this to
developflips the tree to refer to the release branch asreleasebefore the GitHub branch is actually renamed. This is documented-safe: the release branch only ever receives pushes viarelease-cut/release-finalize, both maintainer-controlled. As long as no release is cut between this merge and the branch rename, there is no real gap. Right after merging, please execute w5/w6 per the runbook: setdefault_branch=develop(Decision A, if not already done), thengh api -X POST .../branches/main/rename -f new_name=release, recreate themain-release-onlyruleset asrelease-onlyonrefs/heads/release(same required checks/protections), and update the ruleset-id reference inrepo-admin-settings.md. Ifmake release-cutis accidentally run in the interim it fails fast (gh pr create --base release404s) — no release is silently mis-cut.Review outcome (Opus 4.8 release-criticality review)
An independent adversarial review was run focused on the publish path. Verdict: release-safe.
release.ymlL158) still gated bytest_pypi != 'true' && startsWith(github.ref, 'refs/tags/v'), not loosened;verify-tag-on-main→verify-tag-on-releasecomplete and self-consistent.test.ymlbase_ref conditionals: PASS — all six release-gating conditionals renamed to'release', none missed, no!= 'develop'check wrongly touched, no double-renames.MAIN_CLONE,_project/TODO/main/…paths, blog English prose, andpyproject.toml'sblob/main/CHANGELOG.md— out of this TODO'sscope_limit— all correctly untouched). One doc miss was surfaced and fixed in this PR (results-phase-2-runbook.mdstale deploy-gate refs).Two maintainer notes (out of scope for this TODO, left deliberately):
pyproject.tomlChangelogURL stillblob/main/CHANGELOG.md— outside this TODO'sscope_limit; GitHub redirects renamed-branch blob URLs after w6, so it resolves. Its pinning test is unchanged..github/workflows/seed-corpus.ymlopens PRs with--base mainfromchore/seed-corpus-*heads carrying dev-onlyresults-data/bundles/content (curated off the release branch). This is not release-branch identity — renaming it toreleasewould be wrong (achore/head can't merge to the release-only branch). It reads as integration-branch semantics and likely belongs to the Decision A default-switch item; flagged for the maintainer.Verification
uv run -- python -c "import yaml,glob; [yaml.safe_load(...) for f in glob('.github/workflows/*.yml')]"→ all workflows parse.grep -rn 'refs/heads/main' .github/workflows→ empty;grep -rn -- '--base main' Makefile→ empty;grep 'base release' Makefile→ present inrelease-cut+release-finalize.git cat-file -e v0.1.4:benchbox/core/tpch/*.py(5 paths) andgit cat-file -e v0.2.1:CHANGELOG.mdall succeed.tests/unit/test_release_infrastructure.py→ 38 passed, 2 deselected.todo_cli validate+check-graph→ green (107 items).Type of Change
Chore / release tooling + docs (naming clarity, no behavioral change).
Notes
release.yml→ CODEOWNERS-gated (@joeharris76). This PR must wait for Code Owner review and be sequenced with the coordinated GitHub-side branch rename (w5/w6). Auto-merge is intentionally NOT enabled.🤖 Generated with Claude Code
https://claude.ai/code/session_01JFdZAbavgrKaNLe4YZa3zf
Generated by Claude Code