Conversation
|
Caution Review failedThe pull request is closed. WalkthroughAdds a new GitHub Actions workflow for Chrome Web Store releases, removes the previous release workflow, bumps extension version from 1.0.0 to 1.1.0 (manifest.json and package.json), adds Changes
Sequence DiagramsequenceDiagram
actor GitHub as GitHub (Push / Dispatch)
participant CI as CI Job
participant Builder as Builder (Bun)
participant Validator as Validator (Type/Lint/Test)
participant Packager as Packager
participant CWS as Chrome Web Store API
participant GHRel as GitHub Release
GitHub->>CI: trigger workflow
CI->>CI: checkout repo
CI->>Builder: setup Bun & install deps
Builder-->>CI: deps ready
CI->>Validator: run typecheck, lint, tests
Validator-->>CI: validation result
CI->>Packager: build & package extension
Packager-->>CI: artifact (zip)
CI->>CWS: validate version & extensionId, obtain OAuth token
CI->>CWS: upload artifact
CWS-->>CI: upload status
alt publish requested
CI->>CWS: publish extension
CWS-->>CI: publish status
end
CI->>GHRel: create GitHub Release and attach artifact
GHRel-->>GitHub: release published
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
manuelgruber
changed the title
There was a problem hiding this comment.
Pull request overview
This PR refactors the release workflow from an automated tag-triggered system to a manual-only workflow, providing better control over Chrome Web Store releases. It also fixes a build script issue with stripping inline export declarations and bumps the version to 1.1.0.
Changes:
- Replaced tag-triggered release workflow with manual workflow_dispatch only
- Added Chrome Web Store extension ID to package.json configuration
- Improved build script to strip inline export statements (e.g.,
export function)
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| toolkit/scripts/build.js | Enhanced export stripping to handle inline export declarations for content scripts |
| package.json | Version bumped to 1.1.0 and added chromeWebStore.extensionId field |
| manifest.json | Version bumped to 1.1.0 to match package.json |
| .github/workflows/release-chrome-store.yml | Deleted old automated workflow that supported both tag and manual triggers |
| .github/workflows/Release-Chrome-Web-Store.yml | New manual-only workflow with improved controls and renamed secrets |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "chromeWebStore": { | ||
| "extensionId": "klbbkndjohchnidkbnjijdbggfadpppf" |
There was a problem hiding this comment.
The extension ID format should be validated. Chrome Web Store extension IDs are 32-character strings using lowercase letters a-p (base32 encoding). The provided ID 'klbbkndjohchnidkbnjijdbggfadpppf' is 32 characters and uses only lowercase letters a-p, which appears valid. However, consider adding a validation check in the workflow to ensure the extension ID format is correct before attempting to upload.
| - name: Create GitHub Release | ||
| uses: softprops/action-gh-release@v2 | ||
| with: | ||
| tag_name: ${{ steps.version.outputs.version }} | ||
| name: Clean Autofill ${{ steps.version.outputs.version }} | ||
| files: dist/Clean-Autofill.zip | ||
| generate_release_notes: true | ||
| make_latest: true |
There was a problem hiding this comment.
The GitHub release is created unconditionally, even if Chrome Web Store publishing is skipped (when publish input is false) or fails. The old workflow only created GitHub releases for tag-triggered runs. Consider whether a GitHub release should be created when the extension is not published to the Chrome Web Store, or if the release creation should depend on successful publishing when publish=true.
| publish: | ||
| description: 'Publish to Chrome Web Store after upload' | ||
| required: true | ||
| default: true |
There was a problem hiding this comment.
The default value for the publish input is set to true, meaning the extension will be automatically published to the Chrome Web Store unless explicitly disabled. Consider changing the default to false to require explicit confirmation for publishing, reducing the risk of accidental public releases. This is especially important for a manual-only workflow where the user should consciously decide whether to publish.
| CHROME_WEB_STORE_CLIENT_ID: ${{ secrets.CHROME_WEB_STORE_CLIENT_ID }} | ||
| CHROME_WEB_STORE_CLIENT_SECRET: ${{ secrets.CHROME_WEB_STORE_CLIENT_SECRET }} | ||
| CHROME_WEB_STORE_REFRESH_TOKEN: ${{ secrets.CHROME_WEB_STORE_REFRESH_TOKEN }} |
There was a problem hiding this comment.
Breaking change: The secret names have been changed from the old workflow (CHROME_CLIENT_ID, CHROME_CLIENT_SECRET, CHROME_REFRESH_TOKEN) to new names with CHROME_WEB_STORE_ prefix. This will break existing deployments unless the GitHub repository secrets are renamed to match these new names. Consider documenting this breaking change in the PR description or migration guide, or maintain backward compatibility by checking both old and new secret names.
|
|
||
| if [ "$UPLOAD_STATE" = "SUCCESS" ]; then | ||
| echo "Upload successful" | ||
| echo "access_token=$ACCESS_TOKEN" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
Security concern: The access token is being passed between steps via GITHUB_OUTPUT. While the token is masked at line 124 using ::add-mask::, GitHub Actions' masking may not fully protect values in step outputs, which could potentially expose the token in the workflow interface or logs. A more secure approach would be to obtain a fresh access token in the Publish step using the same OAuth credentials, rather than reusing the token from the Upload step. This eliminates the need to pass the sensitive token between steps entirely.
| echo "access_token=$ACCESS_TOKEN" >> $GITHUB_OUTPUT |
| - name: Create GitHub Release | ||
| uses: softprops/action-gh-release@v2 | ||
| with: | ||
| tag_name: ${{ steps.version.outputs.version }} |
There was a problem hiding this comment.
The workflow creates a GitHub release using only the version number as the tag (e.g., "1.1.0"). While this is valid, it deviates from the common convention of prefixing version tags with 'v' (e.g., "v1.1.0"). The old workflow used 'v' prefix for tags (as seen in the deleted file at line 214: git tag "v$NEW_VERSION"). Consider using "v${{ steps.version.outputs.version }}" to maintain consistency with common Git tagging practices and potentially with existing tags in the repository.
| tag_name: ${{ steps.version.outputs.version }} | |
| tag_name: v${{ steps.version.outputs.version }} |
![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
🤖 Fix all issues with AI agents
In @.github/workflows/Release-Chrome-Web-Store.yml:
- Around line 196-201: The publish step currently only logs warnings on failure,
allowing the workflow to continue; update the conditional that checks STATUS to
make the job fail when publish did not succeed by adding an explicit non-zero
exit in the else branch. Locate the shell block that inspects the STATUS
variable (the if [ "$STATUS" = "OK" ]; then / elif [ "$STATUS" =
"PUBLISHED_WITH_FRICTION_WARNING" ]; then / else ... fi sequence) and change the
else branch to echo an error (or warning) and then run exit 1 so the workflow
fails; leave the OK and PUBLISHED_WITH_FRICTION_WARNING branches unchanged.
🧹 Nitpick comments (1)
.github/workflows/Release-Chrome-Web-Store.yml (1)
23-26: Pin Bun version for reproducible releases instead of usinglatest.Using
latestcan introduce breaking changes across CI/release runs. Pin a version via a dedicated.bun-versionfile (create one in the repository root with just the version number, e.g.,1.xorlatesttag if you want a fixed release channel).Update both occurrences at lines 23-26 and 79-82 from
bun-version: latesttobun-version-file: .bun-version. Alternatively, you could usebun-version-file: package.jsonif you want to couple Bun's version to your extension version, though a dedicated.bun-versionfile is cleaner.Proposed change
- name: Setup Bun uses: oven-sh/setup-bun@v2 with: - bun-version: latest + bun-version-file: .bun-version
Summary
Key Changes
Release-Chrome-Web-Store.ymlworkflow triggered only via workflow_dispatch🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Chores