fix(docs): warn when worker-name is derived rather than pinned - #565
Merged
Conversation
#555 gave this workflow a `worker-name` default derived from `cname` — first label plus "-docs". That is only correct while the hostname and the worker still share a name, and across the fleet they no longer do: integriq.conduction.nl is served by `openconnector-docs`, dossiq.conduction.nl by `procest-docs`, and so on for eight of twelve apps. A derived name that does not exist is NOT an error. wrangler CREATES that worker and deploys to it, while the custom domains keep routing to the real one — the run goes green and the site never changes. That is the same failure this workflow was written to end, reintroduced one layer up by my own default. Measured 2026-08-24: every fleet app had left `worker-name` unset, so every renamed one would have forked its deployment on the first successful publish. They now pin it explicitly. This makes the trap loud for whoever comes next: the input description says PIN IT and explains why, and an unpinned run emits a warning naming the worker it derived and what will happen if that worker is new. The default is kept rather than made required, because a site whose host and worker do share a name is still the common case for a NEW app.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The trap I introduced in #555
#555 gave this workflow a
worker-namedefault derived fromcname— first label +-docs. That is only correct while the hostname and the worker still share a name.Across the fleet they no longer do. Since the app-id rename:
integriq.conduction.nlopenconnector-docsdossiq.conduction.nlprocest-docsfilinq.conduction.nldocudesk-docsbuildiq.conduction.nlopenbuild-docs…and so on for eight of twelve apps.
Why the default is dangerous rather than merely wrong
A derived name that does not exist is not an error. wrangler creates that worker and deploys to it, while the custom domains keep routing to the real one. The run goes green and the site never changes.
That is precisely the failure #555 was written to end — gh-pages written, nothing reading it — reintroduced one layer up by my own default.
Measured 2026-08-24: every fleet app had left
worker-nameunset, so every renamed one would have forked its deployment on its first successful publish. They now pin it explicitly (11 PRs).What this changes
What it deliberately does not change
The default stays, rather than becoming required. A brand-new app whose host and worker do share a name is still the common case, and making it required would break every existing caller to guard against a condition only renamed apps have.