DELIVERY: the gates a week of outside contributions found - #7
Conversation
Seven new sections, each with the thing it caught, following the rule that a gate with no incident behind it does not belong here. The two worth reading first are the ones where something went green that should have gone red. A lint run reported clean because the command was piped through head, so the shell reported head's exit status. And a test library declaring node >=22 ran its whole suite on Node 20, because npm treats engines as advisory; a sibling package declaring the same thing failed loudly, and the loud one was the lucky case. Opening a repository to contributors turned out to test the process rather than the code. A contributor refused a review instruction of mine that would have trusted the host header behind AllowedHosts "*", and was right. Two issues I filed for features that already existed were caught by someone who read the code. The CLA gate blocked the dependency bot's own pull requests. None of it was a code defect and none would have surfaced from another solo month. Also records that barakoCMS publishes before it deploys: test, publish, deploy-playground, so packages go public and only then does anything get observed running. Phase 6 says the opposite. The general form is worth checking anywhere: draw the needs graph and put the irreversible job last, because a bad deploy rolls back and a bad publish does not. Closes with how to keep this file honest, since it is only useful if it is updated at the moment something is learned, which is the moment it is least convenient.
|
Warning Review limit reached
Next review available in: 9 minutes Limit details: You’ve used all 3 included reviews currently available under your plan. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Comment |
The anti-vacuity guard this document recommends was itself written as a grep of console output, and failed a run where all 24 tests passed: CI colours the reporter and a local pipe does not, so ANSI escapes sat between the words the pattern matched on. It passed on a laptop and failed on the runner. Recorded because of when it happened. It was written in the same hour as the section describing that exact failure, by someone who had just finished writing it. That is the argument for gates over intentions, and it belongs in the file rather than in a memory of it.
1 participant
Seven new sections, plus four rows on the signal table and four items on the setup checklist. Every one cites what it caught, per the rule at the top of the file that a gate with no incident behind it is ceremony.
New gates
grepintohead, so the shell reportedhead's status and the failure branch never firednode >=22running its whole suite on Node 20, green, because npm treatsenginesas advisoryjavascript:anddata:text/htmllink destinations rendering live on a static page after raw HTML had been dropped and the job looked finishedThe one I would fix first
barakoCMS's release graph is
test→publish→deploy-playground. Packages and public images go out, and only then does anything get deployed and looked at. Phase 6 of this document says the opposite.The reason it matters is asymmetry rather than thoroughness. A bad deploy is rolled back in a minute. A bad publish is permanent, because registries unlist rather than delete and anyone who already resolved the version keeps it. So the general form, now in the setup checklist: draw the
needs:graph and check the irreversible job is last. It is easy to wire these the wrong way round and never notice, because every individual job is correct.Filed against barakoCMS as BaryoDev/barakoCMS#157.
Signal table
Four rows for things that look like evidence and are not: a piped command's exit status, green tests on a dependency whose
engineswere never enforced, a vulnerability count that predates its own fix, and a200from a link that expires next month.Keeping the file honest
A closing section on updating this at the moment something is learned, with three questions that each produced a section above. The useful one is what went green that should have gone red, because a silent pass gets less attention than a failure and deserves more.
Note on style
The file had no em dashes before this and has none after. I introduced five while drafting and took them back out.