v1.89.0 ·
A new release tag no longer fails open pull requests
On 2026-10-10 autopilot released v1.82.0 and v1.83.0 while three other pull requests were still in CI. Their CI failed with tag v1.83.0 has no manifest entry. Main was green. Nothing in those branches was wrong, and autopilot parked them anyway: 3 of the 10 items in that run.
The cause is that git tags are shared by every checkout, but the blog manifest is not. Every release gets an entry in packages/website/content/blog/manifest.json, and the blog tests check that every tag has one. A pull request branch only has the entries that existed when it last merged main. So the moment a release was tagged, every open branch was missing an entry for a tag it had never seen. Merging main into a branch fixed it with no code change.
What changed
The blog code now reads only the tags it can reach from the commit it is on. In packages/website/scripts/blog/git.mjs that is one flag on each of two git calls:
git tag --list 'v*' --merged HEAD
A release tag sits on a commit of main. A branch that has not merged that commit cannot reach the tag, so the tag is not there for it. A branch that has merged it also has the manifest entry. On main every tag is reachable, all 127 of them, so a tag that really is missing from main's manifest still fails. A new test proves both sides in a throwaway repo, and I checked the fix against the real thing: an old checkout with the v1.88.0 tag present failed 12 tests before the fix and none of them after.
Why this way
The other fix on the table was to make autopilot merge main into a branch before it retries. That only helps autopilot. A pull request I open by hand would still go red. Fixing what the tests read fixes both.
I also did not use "ignore tags newer than the newest manifest entry", the first wording of the idea. It hides too much: a tag that is on the branch but was never added would slip through. Reachability asks the real question, which is whether this tree has seen the tag.
What it does not fix
The bug report named one test. There were five, each listing tags with its own git call, and one of them compared against origin/main, which is exactly the ref that already has the new tag. I only found the other four because the fix applied to the old checkout still failed. They all read tags through the same function now.
One more test was red on main for an unrelated reason while I worked on this: it reads a roadmap file from a folder the file had been moved out of. That is its own item now, not part of this one.