-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix WASM bindings release workflow #1195
Conversation
WalkthroughThe pull request modifies the workflow configuration for releasing WASM bindings. It changes the environment from Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
.github/workflows/release-wasm-bindings.yml (2)
29-32
: Consider pinning exact action version and verifying tool versionsWhile the installation step is well-structured, consider these improvements:
- Pin the action to an exact version (e.g.,
taiki-e/install-action@v2.0.1
) for better reproducibility- Add a version verification step after installation
Add this verification step:
- name: Verify WASM tools run: | wasm-bindgen --version wasm-opt --version
Line range hint
1-63
: Consider adding robustness checks to the workflowTo make the release process more reliable, consider adding:
- Version validation to ensure the package version hasn't been published
- Retry logic for the publish step in case of temporary NPM registry issues
Example implementation:
- name: Validate version working-directory: bindings_wasm run: | PKG_VERSION=$(node -p "require('./package.json').version") if npm view @xmtp/wasm-bindings@$PKG_VERSION version; then echo "Version $PKG_VERSION already exists" exit 1 fi - name: Publish to NPM uses: JS-DevTools/npm-publish@v3 with: token: ${{ secrets.NPM_TOKEN }} package: bindings_wasm retry: 3 retry-delay: 10000 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- .github/workflows/release-wasm-bindings.yml (2 hunks)
🔇 Additional comments (1)
.github/workflows/release-wasm-bindings.yml (1)
13-13
: LGTM! Enhanced security with GitHub-hosted runnerUsing
ubuntu-latest
instead of a custom runner is a good security practice for publishing workflows, as it ensures better supply chain security through GitHub's official infrastructure and enables NPM package provenance.
Summary
wasm-bindgen
andwasm-opt
before buildingSummary by CodeRabbit
wasm-bindgen
andwasm-opt
tools efficiently.