mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-03 10:37:21 +09:00
Myasnikov Daniil
f647e11ace
A second-model review pass found three statements in this branch's own prose that the mechanism contradicts. None overlapped the first pass. The alias claim was the worst of them. docs/release.md said a hand-applied legacy `backport` label "can look ignored for up to a week", which reads as: after the weekly sync renames it, the backport happens. It does not. labels.yaml passes no `token:` to the sync, so it writes as the default GITHUB_TOKEN, and GitHub does not let an event created by that token start a workflow run -- the same rule backport.yaml's own concurrency block is written around. A stray legacy label is a backport nobody delivered, before the sync and after it. What the aliases actually buy is that the stray stays findable, since the audit queries search `label:kind/backport`. Both the doc and the comment in .github/labels.yml now say that instead, and hack/release-freeze-contract.bats pins the coupling: hand that sync a PAT and the documented behaviour changes, with nothing else in the tree connecting the two files. The manual cherry-pick recipe had picked up `--empty=drop`, which git gained in 2.45. Stock Ubuntu 24.04 ships 2.43, where that command fails at option parsing -- including for the ordinary conflict the recipe exists for -- while the prose called the flags harmless. It now uses `--keep-redundant-commits`, which covers both the originally-empty and the already-upstream case on its own (measured), has been in git since well before `--empty`, and keeps a redundant commit visible rather than dropping it, which for a pick someone is watching is the more useful half. `git cherry-pick --skip` is named as the version-independent answer. And "a commit the target branch already carries is dropped, not reported failed" overclaimed at the end-to-end level. At the wrapper level it is exactly right, and that is the case that used to lose a whole backport. But a PR whose every commit is already upstream leaves the branch identical to the target and the action fails opening a PR with no commits in it. That failed before this change too, one step earlier, so nothing regressed -- it is a non-goal, not a fix. The test is rescoped and says so, it now also asserts the case the drop does fix, and docs/release.md carries the reason detecting it up front is the wrong trade: re-deriving which commits the action would pick, merge-strategy detection included, risks skipping a backport that should have happened. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>