Repository navigation
ci(release): switch PyPI watch to JSON API instead of pip index - #70
Merged
Merged
Conversation
The 'Wait for new deepctl version on PyPI' step in the release workflow polled `pip index versions deepctl`, which queries PyPI's simple index behind a CDN cache that can lag 5-15 minutes after a successful publish. v0.2.21 (PR #3 on homebrew-tap) and v0.2.22 (PR #4 on homebrew-tap) both hit this — PyPI confirmed the release was installable, but the cached simple index hadn't picked it up by the time the 10-minute window (30 × 20s) ran out, so bump-brew-formula failed and we had to re-run the formula bump manually. Switch to GET https://pypi.org/pypi/deepctl/<version>/json. That endpoint flips to HTTP 200 the instant a release is published. Same 30 × 20s loop shape, just a different probe — total runtime budget unchanged at 10 minutes worst case but the typical wait should drop to a single iteration. Verified locally that the JSON endpoint already returned 200 for 0.2.22 while `pip index versions` still missed it. No other changes needed — release-please outputs and downstream jobs are untouched.
This was referenced May 8, 2026
dg-coreylweathers
added a commit
that referenced
this pull request
Nov 12, 2026
## Summary After the release workflow opens the "Bump deepctl to X" PR on deepgram/homebrew-tap, it now merges that PR in the same step, using the same `CLI_TAP_SYNC_PAT` that pushed the branch. The step is also made safe to re-run and safe against two releases racing on the tap. ## Why The tap has no branch protection, no checks and no reviewers, so an open bump PR only delays Homebrew users. The 0.3.1, 0.3.2 and 0.3.3 bumps (homebrew-tap #9, #10, #11) all sat unmerged while the tap's formula stayed at 0.2.26. #11 was merged by hand; this keeps that from happening again. The formula is generated from PyPI metadata by `scripts/bump_brew_formula.py`, so there is nothing for a reviewer to judge in the tap PR itself. The merged PR stays as the audit trail, and a broken formula is fixed by editing the template, as the generated PR body already says. ## What changed (`bump-brew-formula` job only) - **Serialized.** The job gets `concurrency: {group: homebrew-tap-bump, cancel-in-progress: false}`, so two root releases in quick succession bump the tap one after the other instead of both reading the same starting formula. - **Version guard.** Before touching git, the step reads the version the tap currently serves from `git show HEAD:Formula/deepgram.rb` (the regenerate step has already overwritten the working tree, so HEAD is the tap's state) and the regenerated version from the working tree. - It fails the job if the tag, the current formula or the regenerated formula is not a plain `X.Y.Z` version, or if the regenerated formula does not point at the tagged version. - It exits 0 with a warning unless the new version is strictly greater than what the tap serves. Re-running an older release can no longer downgrade the tap, and re-running a release that already landed is a no-op. - **Formula syntax check.** `ruby -c Formula/deepgram.rb` runs before the commit. This is a Ruby syntax check only: it catches a broken template or a mangled resource block, not a wrong sha256 or a failing `brew install`. - **Re-runnable push and PR.** The branch is pushed with `--force`, so a re-run replaces a branch left behind by an earlier failed attempt. If an open PR for that branch already exists, it is reused instead of `gh pr create` failing on the duplicate. - The existing-PR lookup only accepts same-repo PRs (`isCrossRepository == false`) authored by the PAT's own login. The tap is public, so anyone can open a fork PR whose head branch is named `bump-deepctl-X`; an unfiltered lookup could have merged it with the PAT. - The resulting PR URL must match `https://github.com/deepgram/homebrew-tap/pull/N` or the job fails. - **Merge with retry.** GitHub computes mergeability after a PR is created and gh does not wait for it, so `gh pr merge <url> --merge --delete-branch` is tried up to five times with a short backoff. If a merge attempt fails but the PR's state is `MERGED` (merged by hand mid-loop, or merged and then the branch delete failed), that counts as success. After five failed attempts the job fails with an error annotation. - **Stale bump cleanup.** After a successful merge, open `bump-deepctl-*` PRs that are same-repo, authored by the PAT owner, and for a strictly older plain `X.Y.Z` version are closed with their branch deleted and a comment linking the superseding PR. This is best effort: listing or closing failures emit a warning and never fail the job. ## Checked - The workflow YAML parses, and `bash -n` passes on the extracted step script. - actionlint 1.7.12 with shellcheck 0.11.0 reports 0 findings on `.github/workflows/release.yml`. The one intentional single-quoted jq `$login` carries a `shellcheck disable=SC2016` with a comment. - No job other than `bump-brew-formula` is modified. - Typed `ci:` so release-please adds no changelog line and bumps no version for CI plumbing (precedent: #66, #70). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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
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.
Problem
The "Wait for new deepctl version on PyPI" step in
.github/workflows/release.ymlpollspip index versions deepctl. That endpoint queries PyPI's simple index, which sits behind a CDN cache that can lag 5-15 minutes after a release is actually published.Two consecutive releases hit this:
In both cases PyPI confirmed the release was installable (any user could
pip install deepctl==X.Y.Z), but the cached index hadn't picked it up before the 10-minute window (30 × 20s) ran out. Thebump-brew-formulajob failed → we had to regenerate the formula manually.Fix
GET https://pypi.org/pypi/deepctl/<version>/json— the PyPI JSON API endpoint flips to HTTP 200 the instant a release is published, no CDN cache between us and the source-of-truth catalog.Same 30 × 20s loop shape, total worst-case budget unchanged at 10 minutes. Typical wait should drop from 5-15 minutes to a single iteration.
Verification
While diagnosing v0.2.22 today:
JSON API: live. Simple index: lagging. The fix is to probe the source of truth.
What it doesn't change
bump-brew-formula's downstream pipeline (homebrew-pypi-poetresource generation, etc.) is unchanged. That step's ownpip install deepctl==<version>may still hit the simple-index lag for ~30-60s after this watch step succeeds, but that's a much smaller window and the install retry is implicit in the script's own behaviour.