ci: remove workflow_dispatch from web-production#54
Merged
lukeocodes merged 1 commit intomainfrom May 4, 2026
Merged
Conversation
Manual production deploys can ship a landing page advertising a version not yet published to PyPI. Lock production deploys to the workflow_call path from release.yml, which is itself gated on a real root v* tag and fires AFTER PyPI publish completes.
lukeocodes
added a commit
that referenced
this pull request
May 4, 2026
## Summary Adds a `publish-on-release.yml` workflow that fires on the `release: published` event, so a human manually creating a GitHub release (with `gh release create v0.X.Y`) can drive the PyPI publish through CI without `workflow_dispatch` and without resorting to local `twine upload`. ## Why Release-please got stuck on PR #50 with `autorelease: pending` after the merge. Every subsequent `release.yml` run aborts at the release-please step (`untagged, merged release PRs outstanding`), so the existing publish path can't fire. PyPI is on 0.2.19, manifest+pyproject on `main` say 0.2.20. Manual recovery options today are: 1. Run `gh release create v0.2.20 ...` to create the release. **But** the existing publish job in `release.yml` is gated on release-please's outputs, not on release events. Manual release alone doesn't trigger publish. 2. Local `twine upload` against PyPI. Bypasses CI entirely. No. 3. `workflow_dispatch` to bypass the release-please gate. **But** `workflow_dispatch` is what got us into the cli.deepgram.com vs PyPI skew the other day. Removed in #54. This PR adds a fourth option, gated on real release artifacts. ## How it works `publish-on-release.yml` triggers on `release: published`. When fired: 1. checks out the released tag 2. installs python + build tools 3. runs `make build` and `make verify-packages` 4. uploads to PyPI via the same `pypa/gh-action-pypi-publish` action and `PYPI_API_TOKEN` secret as the existing publish job It only fires for root tags (`startsWith(github.event.release.tag_name, 'v')`) so sub-package tags like `deepctl-cmd-listen-v0.0.10` continue to flow through `release.yml`. ## No double-publish GITHUB_TOKEN-created releases (which is how release-please's create-release step works) do **not** trigger downstream workflows. GitHub Actions intentionally blocks that loop. So when release-please's normal flow works, `release.yml`'s existing publish job handles it as before, and this workflow stays asleep. This workflow only fires for human-created releases. (Same dynamic that the existing `web-production.yml` comment notes for the workflow_call vs release-published trigger choice.) ## Recovery procedure for v0.2.20 After this lands: 1. `gh release create v0.2.20 --target 2fab886 --title v0.2.20 --notes "$(curl -s 'https://raw.githubusercontent.com/deepgram/cli/2fab886/CHANGELOG.md' | sed -n '/^## \[0.2.20/,/^## /{/^## \[0.2.20/!{/^## /d}};p')"` 2. that fires this workflow → builds + uploads to PyPI 3. relabel `#50`: `autorelease: pending` → `autorelease: tagged` 4. release-please unsticks for future runs ## What this PR doesn't do - doesn't fix release-please's stuck state (manual relabel needed once tag exists) - doesn't trigger any release itself (no `workflow_dispatch`, no scheduled run) - doesn't touch `release.yml` (the normal flow continues unchanged) - doesn't extend `bump-brew-formula` to fire on manual recovery releases (separate concern; brew bump is currently broken anyway due to the `deepgram-robot` 403 issue) ## Verification - `python -c "import yaml; yaml.safe_load(open('.github/workflows/publish-on-release.yml'))"` parses cleanly - only one job, gated on root `v*` tag - uses the same SHA-pinned actions as the existing `release.yml` publish job (`actions/checkout@34e1148...`, `actions/setup-python@a309ff8...`, `pypa/gh-action-pypi-publish@ed0c539...`)
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.
Summary
Removes the
workflow_dispatchtrigger fromweb-production.ymlso manual deploys can no longer fire from the GitHub Actions UI.Why
I triggered a manual
workflow_dispatchon this workflow today to push a doc-only fix that wouldn't have shipped via release-please (docs:doesn't bump). That deployedmainHEAD, which already contained an in-flight version reference (0.2.20) from a merged release-please PR that hadn't actually shipped to PyPI yet. Result: cli.deepgram.com advertised a version users can'tpip install. That should never have happened.Production deploys need to be gated on a real root
v*tag so the landing page never references a version PyPI doesn't have. Theworkflow_callpath fromrelease.ymlalready provides that — it fires AFTERpublishcompletes and only on root tags.What changes
.github/workflows/web-production.yml: dropworkflow_dispatch:from theon:block. Add an inline comment documenting why it's absent so the next person who wants "a manual deploy button for testing" understands the guardrail and proposes a different mechanism instead of just re-adding the line.Out of scope
The current cli.deepgram.com is showing
0.2.20while PyPI tops out at0.2.19. Fixing that is a separate decision — either:0.2.20to PyPI, at which point the deployed page becomes correctI'm not going to touch the live site again without explicit direction.