fix: prerelease command #1532
fix: prerelease command #1532
Conversation
|
Warning Rate limit exceeded@rodrigopavezi has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 24 minutes and 12 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe pull request introduces modifications to the 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 (
|
github-actions
bot
requested review from
aimensahnoun,
alexandre-abrioux,
leoslr and
yomarion
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
.circleci/config.yml (1)
Line range hint
290-296: Review the nightly test workflow configurationThe nightly test workflow is well-structured with:
- Proper scheduling at 22:00 daily
- Correct branch filtering for master
- Appropriate job dependencies
However, consider adding timeout settings for the nightly tests to prevent hung jobs.
test-nightly: docker: - *node_image - *ipfs_image - *ganache_image - *postgres_image - *graph_image + no_output_timeout: 30m working_directory: *working_directoryAlso applies to: 347-367
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.circleci/config.yml(1 hunks)package.json(1 hunks)
🔇 Additional comments (2)
package.json (1)
28-29: Verify impact of removed publishing flags
The removal of several flags from both publishing scripts might have unintended consequences:
--conventional-commits: Might affect version bumping consistency--exact: Could allow floating versions--no-verify-access: Might cause npm registry access issues
✅ Verification successful
Removed flags are safely handled by other configurations
The removal of the flags appears to be safe because:
--conventional-commitsis still present in the mainpublish-npmscript, which maintains version bumping consistency for production releases--exactis not critical for prerelease versions as they are tagged withnextand won't affect production dependencies--no-verify-accessremoval is safe as npm registry access can be verified through standard authentication
The prerelease scripts are specifically designed for development/testing purposes (using --no-push and next tag), so the removed flags won't impact production releases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if conventional commits are being used in the repository
# and if exact versions are enforced in package.json files
# Check if conventional commits are used in recent commits
echo "Checking recent commit messages for conventional commit format..."
git log -n 10 --pretty=format:"%s" | grep -E "^(feat|fix|docs|style|refactor|perf|test|chore|revert|build|ci)(\(.+\))?: .+"
# Check if exact versions are used in dependencies
echo -e "\nChecking for non-exact versions in package.json files..."
fd -e json -x jq -r '.dependencies,.devDependencies,.peerDependencies | select(. != null) | to_entries[] | select(.value | startswith("^") or startswith("~")) | .key + ": " + .value' {} \;
Length of output: 679
Script:
#!/bin/bash
# Let's try a different approach to verify the impact
# 1. Check for lerna.json configuration
echo "=== Checking lerna.json configuration ==="
cat lerna.json
# 2. Check for any npm or yarn configuration files that might enforce versioning
echo -e "\n=== Checking for npm/yarn configuration files ==="
fd -e npmrc -e yarnrc -e yarnrc.yml
# 3. Look for commit message configuration
echo -e "\n=== Checking for commit message configuration files ==="
fd -g '*commit*' -g '.czrc' -g '*lint*' -t f
# 4. Check package.json for any relevant configuration
echo -e "\n=== Checking package.json configuration ==="
cat package.json | jq '{
"commitlint": .commitlint,
"config": .config,
"husky": .husky,
"dependencies": .dependencies,
"devDependencies": .devDependencies
}'
Length of output: 1618
Script:
#!/bin/bash
# Let's check for commit hooks and lint configurations
# Check for husky configuration
echo "=== Checking for husky configuration ==="
fd -g '.husky' -t d -x ls -la {}
# Check for commitlint configuration file
echo -e "\n=== Checking for commitlint configuration ==="
fd -g 'commitlint.config.js' -g '.commitlintrc*'
# Check for lint-staged configuration
echo -e "\n=== Checking for lint-staged configuration ==="
cat package.json | jq '.["lint-staged"]'
# Check for version-related scripts in package.json
echo -e "\n=== Checking version-related scripts ==="
cat package.json | jq '.scripts | with_entries(select(.key | test("version|publish|release")))'
Length of output: 1416
.circleci/config.yml (1)
Line range hint 290-296: Ensure consistent publishing behavior across CI and local environments
The publishing command in CircleCI matches the simplified version in package.json, which is good for consistency. However, verify that the environment variables and npm authentication are properly set up for the new simplified command.
✅ Verification successful
NPM authentication and publishing configuration is properly set up
The verification shows that:
- NPM authentication is correctly configured using
NPM_TOKENin the CI environment - The token is properly set in
.npmrcbefore publishing - The publishing command in CI matches the
publish-prereleasescript in the root package.json - The force publish calculation is consistent between CI and package.json scripts
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if NPM_TOKEN is properly set in CircleCI context
# Check if the context exists and contains NPM_TOKEN
echo "Verifying NPM_TOKEN in CircleCI context..."
gh api -X GET "/orgs/${CIRCLE_PROJECT_USERNAME}/contexts" | jq '.[] | select(.name == "protocol-release")'
Length of output: 265
Script:
#!/bin/bash
# Let's verify the npm authentication setup in the CI configuration
rg -A 5 "NPM_TOKEN|npm.*token" .circleci/config.yml
# Also check for any npm authentication steps in the workflow
rg "npm.*auth" .circleci/config.yml
# Check the publishing job configuration
rg -A 10 "publish:" .circleci/config.yml
Length of output: 496
Script:
#!/bin/bash
# Let's check the complete workflow and job configuration for the publishing step
rg -B 5 -A 15 "jobs:" .circleci/config.yml
# Also check package.json for any npm-related scripts
fd package.json --exec cat {} | jq '.scripts'
Length of output: 11283
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Description of the changes
This is an attempt to fix the prerelease. When running locally I see this version output.
Summary by CodeRabbit
New Features
Improvements
package.jsonscripts for manual and automated prerelease processes.Bug Fixes