feat: setup npm publish workflow via github actions#156
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (7)
WalkthroughA new release workflow tags and publishes ChangesVersion Release Pipeline
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
landing-page/src/components/CodeShowcase.tsxESLint skipped: missing config or dependency (missing-dependency). The ESLint configuration references a package that is not available in the sandbox. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/version-release.yml:
- Around line 63-79: The tag creation check in the "Check if tag already exists"
step currently fails whenever a tag exists, which prevents workflow reruns from
recovering after transient failures. Instead of simply checking if the tag
exists, verify that an existing tag points to the current commit (use git
rev-list or git show-ref with filtering to compare the tag's commit against the
HEAD commit). Only exit with error if the existing tag points to a different
commit, allowing reuse of tags that point to the current commit to make the
workflow idempotent for workflow_dispatch reruns.
- Around line 178-186: The "Verify package contents" step with npm pack
--dry-run runs before the "Sync version from VERSION file" step, which means it
validates the package metadata with the old version instead of the version that
will actually be published. Move the entire "Verify package contents" step that
contains npm pack --dry-run to execute after the "Sync version from VERSION
file" step so that the dry run checks the exact artifact with the correct synced
version before npm publish occurs.
- Line 25: Replace all mutable action version tags in the workflow file with
immutable full commit SHAs. Specifically, update the actions/checkout action at
line 25 and the other action references mentioned (at lines 31, 85, 155, 160,
and 166) from their current format using tags like `@v4`, `@v7`, and `@v3` to use the
full commit SHA format (e.g., uses: actions/checkout@<full-sha-hash>). Obtain
the latest commit SHA for each action from its repository and replace the
version tag accordingly.
- Around line 47-61: The Read VERSION file step exports the version to
GITHUB_OUTPUT before validation occurs, allowing invalid content to propagate
through the workflow. Move the semantic versioning validation logic (the regex
check for pattern matching ^[0-9]+\.[0-9]+\.[0-9]+$) into the Read VERSION file
step and perform it before executing the echo "version=$VERSION" >>
$GITHUB_OUTPUT command. This ensures the version is validated immediately after
reading and only exported if it passes the validation check.
- Around line 11-12: Move the `contents: write` permission from the
workflow-level permissions to only the `release` job where it is actually
needed. Remove the `permissions: contents: write` block at the workflow level
and instead add a `permissions:` section directly within the `release` job with
`contents: write`. Set the workflow-level permissions to `contents: read` to
ensure the `publish` job and any future jobs default to read-only access unless
explicitly granted write permissions.
- Around line 3-9: Add workflow-level concurrency control to the
version-release.yml workflow to prevent simultaneous runs from racing when
creating release tags. Add a concurrency section at the top level of the
workflow configuration (after the on trigger definition) that groups runs by the
workflow name or a static identifier, and set cancel-in-progress to false to
ensure runs are serialized rather than cancelled, preventing the race condition
where multiple runs can pass the tag existence check before any of them
successfully creates the tag.
- Around line 24-29: The checkout action is configured with persist-credentials
set to false, which prevents GitHub from automatically configuring git
credentials, but the subsequent git push command on line 78 (git push origin
"v$VERSION") has no authentication mechanism in place. Either change
persist-credentials to true in the checkout action to allow automatic credential
persistence, or before the git push command, configure git to use the
GITHUB_TOKEN for authentication by setting up a credentials helper or using git
config to authenticate with the token, ensuring the tag push will succeed with
proper authentication.
- Around line 91-99: The draft release lookup in the code does not filter by the
current version's tag, creating a risk of publishing an unrelated draft release
if multiple drafts exist. Modify the draftRelease variable assignment to filter
not only by draft status but also by matching the version tag from the current
context. Additionally, implement pagination handling when calling
github.rest.repos.listReleases to ensure all draft releases are considered
beyond the default 30-result limit, rather than just finding the first draft in
the response.
In `@package.json`:
- Line 2: The package name has been updated to the scoped name
"`@aossie-org/social-share-button`" in package.json, but documentation and lock
file metadata still reference the old package name "social-share-button-aossie".
Replace all occurrences of "social-share-button-aossie" with
"`@aossie-org/social-share-button`" in the installation/import examples found in
the client guide documentation, README installation sections, and update the
package-lock.json metadata to reflect the correct scoped package name to ensure
consistency across all downstream references before release.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 835fc576-24ba-484b-b1e0-d032fd439233
📒 Files selected for processing (3)
.github/workflows/version-release.ymlVERSIONpackage.json
|
Please resolve the merge conflicts before review. Your PR will only be reviewed by a maintainer after all conflicts have been resolved. 📺 Watch this video to understand why conflicts occur and how to resolve them: |
78e2b6c to
bd487b4
Compare
Addressed Issues:
Fixes #(issue number)
Screenshots/Recordings:
Additional Notes:
This PR configures the automated GitHub Actions workflow for publishing the
SocialShareButtonpackage to npm.Key Changes:
package.jsonto the scoped@aossie-org/social-share-buttonto correctly publish under the organization.VERSIONfile: Added aVERSIONfile (starting at1.0.3) which acts as the trigger for the automated tag and release process.version-release.yml: Added the CI workflow that automatically creates GitHub tags/releases and publishes the package to npm using the organization's token when theVERSIONfile is updated.pnpmand runspnpm run lintbefore packaging to ensure code quality.Checklist
We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact. AI slop is strongly discouraged and may lead to banning and blocking. Do not spam our repos with AI slop.
Summary by CodeRabbit
New Features
Chores
@aossie-org/social-share-button(scoped package)Documentation