Repository navigation
[PR] fix(release): label-gated head-tree publish for conflicted carve-out ship PRs - #4596
Conversation
ranxianglei
changed the title
📦 Built Package ArtifactBranch: Latest build — install this exact versionnpm install -g billion-context@0.0.5671-pr.4596.ec86ca4This exact version is immutable and reproducible. The rolling Recent builds (commit → version)
Download artifact
tar xzf billion-context-pr4596.tgz
npm install -g packageInstall instructions are refreshed on each push. |
(ai: vllm-qwen/qwen3.8-27b) 结论先行:本车道点名的 查重:不重复——这是 #4596 自身 CI 的自动修复车道;根因与 master 侧记录(#4602→#4603、#4599 盘点第 1 条)同源,但那是 master 侧条目,本车道是独立触发、独立收口。 八问:
关于 test 分片(顺带核实,非本车道范围):当前 head 上 11 个 test 分片全红,但一行测试都没跑——死在 pretest 自检: 收工判定: |
(ai: vllm-qwen/qwen3.8-27b) 查重: 不重复。 open+closed issue/PR 检索(机制关键词 + CI 失败签名):无既有「label-gated head-tree publish」条目或在途同类 lane 修复 PR。背景引用(非重复):#2011/#2851(bugfix carve-out 通道)、#4449(manifest sync)、#4576(release-manual existence-guard 哲学)。 标签: bug / scope/ci / p2 — 发版管道缺陷(conflicted carve-out lane 无法发布);bili 用户运行时不受影响,故 p2 非 p1。 审查中状态(head
接下来:workflow 变更全量审查(resolve gate、guards、publish 路径)+ 处置那条 LIVE_FILES 继承红。 |
(ai: vllm-qwen/qwen3.8-27b) 重复/过期通知——本条针对的 head |
…aster Review finding on #4596: the labeled path lacked the base-branch filter the closed-PR path carries, and its comment claimed pull_request_target does not support one -- false per GitHub docs (on.<pull_request_target>.<branches> is matched against the PR base). A backport-ship label on a PR targeting any non-master branch would arm the publish path (still version-guarded, but needlessly). Add branches: [master] to match the closed-PR trigger and fix the comment.
(ai: vllm-qwen/qwen3.8-27b) 审核完成:结论为通过。 独立通读了全部 diff(3 文件)+ 新 workflow 全文(381 行)+ 结构化八问:
CI 状态与新 head
动作清单:标签已打(bug/p2/scope/ci,见前一条);收紧 commit 判定:审核通过,可以合。 合并权在你(human-only)。合并后按正文测试计划执行:v0.1.207 ship PR( |
…same one-word fix as ranxianglei#4606 commit 1; duplicate in-branch per CI-coordination precedent ranxianglei#4607/ranxianglei#4595/ranxianglei#4596, drop on rebase after ranxianglei#4606 merges)
…ship PRs A patch lane cut from an old tag whose fixes already landed on master conflicts with master at ship time: the merge button refuses, resolving on the lane would leak unreleased master work into the published head tree, and resolving on master needs a direct master push. Also, lanes cut from old tags carry an old release-bugfix.yml that predates the bugfix-v* marker, so even a clean merge would silently skip publish. - add pull_request_target [labeled] trigger: the carve-out-ship label on an OPEN same-repo ship PR (bugfix-v* / bugfix-release/* head) publishes the PR head tree with every existing guard + full gate, no merge needed - run the master copy of the workflow (pull_request_target), fixing the old-tag lane marker gap for this path - manifest sync check fails open with a notice on pre-#4449 trees (same existence-guard philosophy as release-manual's lane guard, #4576) - annotate the ship PR after publish (audit trail; publish != merge) - document the label path in reference/release.md (carve-out + ship-the-lane)
…arry family prefix)
…aster Review finding on #4596: the labeled path lacked the base-branch filter the closed-PR path carries, and its comment claimed pull_request_target does not support one -- false per GitHub docs (on.<pull_request_target>.<branches> is matched against the PR base). A backport-ship label on a PR targeting any non-master branch would arm the publish path (still version-guarded, but needlessly). Add branches: [master] to match the closed-PR trigger and fix the comment.
eb483c6 made every BILI_DUMP_4XX err/summary-err dump lead with DUMP_PLAINTEXT_BANNER, but the cap budget still measured only the body, so every file overshot the operator's byte knob by exactly the banner (1024-cap file => 1111 bytes) and the #4297 final-UTF-8-bytes contract plus the JSON.parse assertions went red on master (masked until the LIVE_FILES tripwire stopped failing shards first). - cappedBudget(): knob minus banner bytes (floor 0), used by both dumpRejectedBody and dumpSummaryRejection so the file on disk honors the cap - #4297 tests: stripDumpBanner before exactness/JSON asserts and banner-aware boundary budgets, matching how issue1993/reasoning-echo already consume these dumps
df240a5 to
d515aea
Compare
(ai: vllm-qwen/qwen3.8-27b) 冲突已解决:分支已重建到当前 master tip( 做了什么:master 自分支基点( 本地验证(定向,非全量): 需你知晓的一点: 结构化八问:
收工判定:冲突解决完毕,PR 处于可合并状态(等 |
📦 Merged Build PublishedThis merge to master was published as npm install -g billion-context@0.0.829-master.bd29924 # this exact build
npm install -g billion-context@master # always the newest merged build
|
Problem
Two gaps found while shipping v0.1.207 through the patch lane:
Conflicted ship PRs are unpublishable by design. A lane cut from an old tag (e.g.
bugfix-v0.1.206= v0.1.206 tag + backported fixes) conflicts with master at ship time when those fixes already landed on master and master moved on (renames, follow-ups touching the same files). GitHub's merge button then refuses. The two available resolutions are both unacceptable:Never merge master into a lane);Old-tag lanes carry an old
release-bugfix.yml. Thebugfix-v*head marker was added to this workflow only on master (10-24); a lane cut from v0.1.206 ships the 206-era copy, which only recognizesbugfix-release/*— so even a cleanly mergeable ship PR would publish NOTHING (silent notice). Thepull_requestclosed event runs the head's copy of the workflow.Change
pull_request_target: [labeled]trigger: adding thebackport-shiplabel to an OPEN, same-repo ship PR whose head branch matchesbugfix-v*/bugfix-release/*publishes the PR HEAD tree — no merge into master required.labeledfires on ADD only, so the gate is a deliberate triage-capable human action. Every existing guard (monotonic vs npm latest, not-already-live, no sub-0.1.0, release-notes ON THE REF) and the full gate (npm ci+ typecheck + test + build + full-CI gate at the publish sha) still run. Fork PRs are rejected as before.inputs.fastis meaningless on this event, so the label path is always full-gate.backport(route a fix) →backport-carry(lane carry PR) →backport-ship(publish the lane). Same pattern asci:full.pull_request_targetruns the master copy of the workflow, gap 2 is fixed for this path automatically.reference/release.md: new "Conflicted ship PRs (label publish)" paragraph + a pointer in "Ship the lane".Label
backport-shiphas been created on the repo.Security notes
pull_request_targetdiscipline.npm ci && npm test && npm run build), same trust as a merged ship PR; the labeler must have triage permission on the repo.pull-requests: writeadded (post-publish comment only).Validation
python3 -c yaml.safe_loadon the workflow — OK.jqpaths exercised): backport-ship on open same-repobugfix-release/*andbugfix-v*PRs →proceed=truewith correct branch/sha; other labels / closed PR / fork PR / non-marker head → notice-exit or fork-error as designed.bash -non the extracted script — OK.Test plan
After merge: open the v0.1.207 ship PR from
bugfix-release/v0.1.207-storage-backport(head = current lane tipec5d3e3e, tree = v0.1.206 tag + 5 storage fixes + notes + bump + 3 diagnostics), wait for its CI, applybackport-ship→ expect publish of the pure head tree with all guards green.