Repository navigation
docs(contributing): releasing.rst documents the cascade guard with the rejected spelling #958
Description
docs/source/contributing/releasing.rst:176-177 states the cascade guard with the wrong spelling — the one the workflow explicitly rejects. Found by a cross-review on #957.
What the page says:
The three jobs here do the same for each of their own direct dependencies:
!cancelled() && needs.<job>.result != 'failure'.
No job in create-release.yml uses that form. tag (:447), pypi (:525) and conda (:625) all spell it:
!cancelled() && needs.version_check.result == 'success' &&
(needs.github.result == 'success' || needs.github.result == 'skipped') && ...
The only two occurrences of != 'failure' in the file are comments explaining why it is not used, at :119 and :124-128:
… rather than the sibling files'
!= 'failure'--!= 'failure'alone still admitscancelled, and a cancelledtagwould sendcondainto itsactions/checkoutwithref: conda-<version>+0for a tagtagnever pushed, trading a clean skip for a checkout failure.
So the page documents a guard that would reintroduce the defect the real guard was written to avoid. tests/project/test_release_gates.py:624 pins this directly — assertNotIn(f"needs.{dep}.result != 'failure'", condition) — so the behaviour is tested and only the prose disagrees.
The surrounding paragraph is right about everything else, including that cron-vendor.yml, deploy-pages.yml and cron-conda.yml do use != 'failure' for needs.unit-tests.result. The error is confined to the sentence generalising that to the three publishing jobs. Fix is to give the two-state spelling and say why it differs from the sibling files.
Note #953 currently owns releasing.rst and is open with a cross-review verdict, so this wants either its own change after #953 merges, or a deliberate decision to fold it in.
Activity
JarryShaw commentedon Oct 1, 2026
Blocked on #953, and the blocker is checkable rather than remembered:
While that returns
OPEN, this stays blocked. #953 is the open prose sweep that ownsdocs/source/contributing/releasing.rst; it carries areview: good-to-goverdict at7c6b8a681and editing the same file now would turn a reviewed diff into an unreviewed one.When it returns
MERGED, this unblocks and wants its own one-paragraph change.JarryShaw commentedon Oct 1, 2026
Unblocked — #953 merged as
31b01dbc5(04:25:22Z), and it did not fix this. The blocker I posted above is spent;releasing.rstis now free to edit.Re-verified on current
mainrather than from memory,:168-175:A verification trap worth recording for whoever picks this up:
grep "!= 'failure'" docs/source/contributing/releasing.rstreturns only:171, which is the correct occurrence — the one aboutneeds.unit-tests.resultin the sibling workflows. The wrong one wraps across a line break (needs.<job>.result !=/'failure'), so a single-line grep misses it. Read the paragraph, or normalise whitespace first.Picking this up now.
ci(create-release): scope the cascade-guard comment to the publishing…
ci(create-release): scope the cascade-guard comment to the publishing…
docs(contributing): correct releasing.rst's cascade guard (#958) (#959)
ci(create-release): scope the cascade-guard comment to the publishing…
ci(create-release): scope the cascade-guard comment to the publishing…
ci(create-release): scope the cascade-guard comment to the publishing…