Skip to content

docs: the publish window is wider than four minutes - #57

Merged
elvogel merged 2 commits into
mainfrom
docs/the-publish-window-is-wider-than-four-minutes
Oct 16, 2026
Merged

elvogel merged 2 commits into
mainfrom
docs/the-publish-window-is-wider-than-four-minutes

Conversation

@elvogel

@elvogel elvogel commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Comment only, in .github/workflows/release.yml. Nothing executable changes.

The Version is not already published gate reads the flat-container index, and the comment
above it recorded the index's lag behind a push as "roughly four [minutes] for 0.2.5" -- one
measurement, from one release.

Publishing 0.3.0 gave a second one, and it is worse. Measured from the moment the Publish step
succeeded:

Signal When
flat container lists the version 400 s
dotnet tool install --version 0.3.0 resolves about 560 s, 160 s after the listing

Before that last point the install answered Version 0.3.0 of package docmd.cli is not found in NuGet feeds, so the registration and search services lag the flat container again.

The comment now says to treat the window as about ten minutes rather than four, and records
which signal is the slow one. A fresh install looks like the stronger check and is actually the
later one, so it cannot be the gate either.

The gate itself is unchanged and so is the hole it leaves -- a re-tag inside the window -- which
is still much narrower than the hole it closes: --skip-duplicate makes a re-tag of a published
version go green while uploading nothing.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wZEgtuzaZPswykiGEBxbz

Lucas Vogel and others added 2 commits October 15, 2026 21:19
The release workflow's "Version is not already published" gate reads the
flat-container index, which lags the push. The comment recorded that lag as
roughly four minutes, measured once, on 0.2.5.

0.3.0 took 400 seconds. At the moment the index first listed it,
`dotnet tool install --version 0.3.0` still answered "not found in NuGet
feeds", because the registration and search services lag the flat container
again. So the window to treat as unsafe for a re-tag is about ten minutes, not
four, and a fresh install is the slower signal rather than the earlier one.

Comment only. The gate is unchanged, and so is the hole it leaves: a re-tag
inside the window, which is still narrower than the hole it closes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018wZEgtuzaZPswykiGEBxbz
The first commit said only that `dotnet tool install` could not resolve 0.3.0
at the moment the flat container listed it. It resolved 160 seconds after that,
which puts a usable install about ten minutes after the push and is the
measurement the "ten minutes rather than four" rests on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018wZEgtuzaZPswykiGEBxbz
@elvogel
elvogel merged commit 11889c9 into main Oct 16, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant