Neither dsh.works nor dshthemes.com has deployed since 2026-08-20. Two separate causes, one of which needs a credential only a human has.
dsh.works — deploy fails loudly, and nobody was reading it
deploy.yml has failed on every run since 2026-08-20 (5 scheduled, 2 push):
##[error]missing repository secret(s): CLOUDFLARE_API_TOKEN CLOUDFLARE_ACCOUNT_ID
The preflight step is working exactly as designed — it fails before the four-minute build and prints the command that fixes it. The gap is that a red run on a scheduled workflow is invisible unless someone goes looking, and nobody did for four days.
Meanwhile the live site advertises 9,341 plugins, built 2026-08-21 in its <title>, its OG tags and its llms.txt. The registry is at 9,324 — the difference is real: 7 contributor merges, 70 applied renames, and 22 rows that were the same plugin listed twice.
That is precisely the failure the workflow's own header comment names:
A stale number that looks fresh is the exact failure it exists to criticise.
The counts are all templated from meta.json, so they self-correct the moment a deploy succeeds. Nothing to fix in the site code.
dshthemes.com — worse, because it failed silently
refresh.yml used if: ${{ secrets.CLOUDFLARE_API_TOKEN != '' }}. That is not a step that skips — secrets is not a valid context in an if:, so GitHub rejected the whole file and the workflow has not run at all since 2026-08-19. No nightly, no dispatch.
It presented as failed runs marked "This run likely failed because of a workflow file issue", triggered by push on a workflow that has no push trigger, with gh run view --log-failed returning log not found because nothing ever started. Easy to read as a flake. gh workflow run is what named it: HTTP 422 … Unrecognized named-value: 'secrets'.
Fixed in dshworks/dshthemes#1 — the gate goes through env and is tested in the shell. Dispatched twice since, both green, and the registry data is now committed and current: 417 themes, 162 shots (was 393/150).
What is still needed
The same two secrets, on both repos. I cannot set these.
gh secret set CLOUDFLARE_API_TOKEN --repo dshworks/plugins
gh secret set CLOUDFLARE_ACCOUNT_ID --repo dshworks/plugins
gh secret set CLOUDFLARE_API_TOKEN --repo dshworks/dshthemes
gh secret set CLOUDFLARE_ACCOUNT_ID --repo dshworks/dshthemes
The token needs Workers Scripts: Edit. There are no org-level secrets set either, so an org secret scoped to both repos would work too and would be one place to rotate.
Once set, dsh.works deploys on its next push or at 03:42 UTC, and dshthemes.com at 03:17 UTC.
Worth fixing separately: nobody notices a red schedule
Both failures lasted days because a failing scheduled workflow notifies no one. dsh-meter already solves this — its pricing job opens a pricing-drift issue when it cannot finish, which is how the vision-model gap got found. The same on: failure → open-or-update-an-issue step belongs on both deploy workflows.
Neither
dsh.worksnordshthemes.comhas deployed since 2026-08-20. Two separate causes, one of which needs a credential only a human has.dsh.works — deploy fails loudly, and nobody was reading it
deploy.ymlhas failed on every run since 2026-08-20 (5 scheduled, 2 push):The preflight step is working exactly as designed — it fails before the four-minute build and prints the command that fixes it. The gap is that a red run on a scheduled workflow is invisible unless someone goes looking, and nobody did for four days.
Meanwhile the live site advertises 9,341 plugins, built 2026-08-21 in its
<title>, its OG tags and itsllms.txt. The registry is at 9,324 — the difference is real: 7 contributor merges, 70 applied renames, and 22 rows that were the same plugin listed twice.That is precisely the failure the workflow's own header comment names:
The counts are all templated from
meta.json, so they self-correct the moment a deploy succeeds. Nothing to fix in the site code.dshthemes.com — worse, because it failed silently
refresh.ymlusedif: ${{ secrets.CLOUDFLARE_API_TOKEN != '' }}. That is not a step that skips —secretsis not a valid context in anif:, so GitHub rejected the whole file and the workflow has not run at all since 2026-08-19. No nightly, no dispatch.It presented as failed runs marked "This run likely failed because of a workflow file issue", triggered by push on a workflow that has no push trigger, with
gh run view --log-failedreturninglog not foundbecause nothing ever started. Easy to read as a flake.gh workflow runis what named it:HTTP 422 … Unrecognized named-value: 'secrets'.Fixed in dshworks/dshthemes#1 — the gate goes through
envand is tested in the shell. Dispatched twice since, both green, and the registry data is now committed and current: 417 themes, 162 shots (was 393/150).What is still needed
The same two secrets, on both repos. I cannot set these.
The token needs Workers Scripts: Edit. There are no org-level secrets set either, so an org secret scoped to both repos would work too and would be one place to rotate.
Once set,
dsh.worksdeploys on its next push or at 03:42 UTC, anddshthemes.comat 03:17 UTC.Worth fixing separately: nobody notices a red schedule
Both failures lasted days because a failing scheduled workflow notifies no one.
dsh-meteralready solves this — its pricing job opens apricing-driftissue when it cannot finish, which is how the vision-model gap got found. The sameon: failure→ open-or-update-an-issue step belongs on both deploy workflows.