External/roboco
1
0
Fork 0
mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs(release): prepare 0.27.0 — curated changelog, rag/map sweep, concat rebuild script (#662)

Browse Source
This commit is contained in:
Renzo F
2026-07-23 11:33:02 +02:00
committed by GitHub
parent d8841279a8
commit dd4c3c3ed0
26 changed files with 501 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/map/release-manager.md
+1
View File
@@ -255,6 +255,7 @@ release-manager slice
> - b3558d4e [chore] complexity: split 5 C-rank blocks to <=B for the xenon gate — refactored large methods in executor/proposal for xenon compliance; no behavior change.
> - 8621d01d / fe9940de / d80dfb8b (#534, env-branches ladder) — replaces `default_branch`-keyed release targeting: `_ReleaseContext` gains `prod_branch` (renamed from `default_branch`) + `env_chain`; `get_release_executor` resolves the clone/commit/tag target via `roboco.models.env_branches.prod_branch` and computes `env_chain` via `promotion_chain`; `_GitReleaseOps` gains `promote_env_chain` (fetch + head-first merge of `env_chain` into the prod checkout, fail-closed `promotion_failed` on conflict), run as the first step of `_run_fresh_release`, before any version bump; `release_readiness.gather_snapshot` takes an optional `prod_branch` and diffs `prod..head` (falling back to `last_tag..HEAD` when unset) with a new `_tag_drift_gaps` check (last-tag sha vs. prod tip); `release_manager_engine._production_assess` best-effort fetches the prod rung into the head-pinned read clone before gathering the snapshot. A project with no declared ladder is unaffected (the shim resolves prod_branch/head_branch to the same `default_branch` value).
> - `11915f36` (PR #551, Telegram V2 security follow-up) — `_approve_precheck` (new) makes `approve()` refuse a CANCELLED proposal (`already_rejected`) or a COMPLETED one (`already_published`) BEFORE touching the Redis lock/executor; `reject()` now raises the new `TaskAlreadyCompletedError` on a COMPLETED proposal instead of silently cancelling an already-public release. Closes a live-reproduced approve-after-reject hole reachable via a stale Telegram Approve button (or a replayed HTTP call).
> - `f74131a1` ("commit the approve() COMPLETED write under the release lock"): `approve()` used to `flush()` the published proposal's COMPLETED status and leave the durable commit to the background caller (`_run_approve_background`), which runs AFTER `approve()`'s `finally` has already released the Redis lock — in that window a concurrent `reject()` could acquire the freed lock, re-read a row whose COMPLETED write was only flushed (invisible to its own session under READ COMMITTED), pass its guard, and flip the just-published proposal to CANCELLED (last writer wins). The earlier bug-sweep (#638) fixed `reject()`'s side of this race but left `approve()`'s, so `reject()`'s "fails closed on a terminal proposal" guarantee didn't hold end to end. `approve()` now `commit()`s COMPLETED WHILE STILL HOLDING the lock (mirroring `XPostService._post`'s commit-under-lock), so it's durable before release and a racing reject sees it and refuses.
## Regression Risks