Publish chrome extension with github actions#13
Conversation
Co-authored-by: cursor.com <cursor.com@manuelgruber.com>
Co-authored-by: cursor.com <cursor.com@manuelgruber.com>
|
Cursor Agent can help with this pull request. Just |
WalkthroughThis PR establishes automated Chrome Web Store publishing infrastructure via GitHub Actions workflows, introduces semantic versioning without "v" prefix, implements version synchronization across manifests, adds comprehensive documentation covering publishing, CI, and workflow processes, and provides a version-bumping helper script. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Git as Git/GitHub
participant CI as CI Workflow
participant Publish as Publish Workflow
participant CWS as Chrome Web Store
participant Release as GitHub Release
Dev->>Dev: Run bump-version.sh
Dev->>Git: Commit version changes
Dev->>Git: Push tag (X.Y.Z format)
Git->>CI: Trigger on tag push
CI->>CI: Checkout, setup Node
CI->>CI: Install dependencies
CI->>CI: Run tests
CI->>CI: Build extension
CI->>CI: Validate dist/ contents
Git->>Publish: Trigger on tag push
Publish->>Publish: Checkout, setup Node
Publish->>Publish: Install & test
Publish->>Publish: Build extension
Publish->>Publish: Create ZIP (baitbreaker-X.Y.Z.zip)
Publish->>CWS: Upload to Chrome Web Store
Publish->>Release: Create GitHub Release
Release->>Git: Tag published
Publish->>Dev: Success notification
sequenceDiagram
participant Dev as Developer
participant PR as Pull Request
participant CI as CI Workflow (PR)
participant Check as version-check Job
Dev->>PR: Create/update PR
PR->>CI: Trigger CI workflow
CI->>CI: test job (checkout, Node setup, test, coverage, build)
CI->>CI: Validate dist/ structure
CI->>Check: version-check job starts
Check->>Check: Fetch package.json version
Check->>Check: Fetch manifest.json version
alt Versions Match
Check->>CI: ✓ Pass
CI->>PR: Success status
else Versions Differ
Check->>CI: ✗ Fail
CI->>PR: Blocked (version mismatch)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull Request Overview
This PR sets up automated publishing infrastructure for the BaitBreaker Chrome extension, enabling continuous deployment to the Chrome Web Store via GitHub Actions.
Key Changes:
- Automated publishing workflow triggered by semantic version tags (e.g.,
1.0.0) - CI/CD pipeline with comprehensive testing, building, and validation steps
- Version management script to synchronize versions across
package.json,manifest.json, andpackage-lock.json
Reviewed Changes
Copilot reviewed 11 out of 12 changed files in this pull request and generated 21 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/publish.yml |
Automated workflow to build, test, and publish extension to Chrome Web Store on version tag pushes |
.github/workflows/ci.yml |
Continuous integration workflow for testing, building, and validating on all pushes and PRs |
scripts/bump-version.sh |
Bash script to automate version bumping across all package files with validation |
package.json |
Added npm scripts for packaging, version checking, and pre-build validation hooks |
.gitignore |
Added coverage reports and ZIP build artifacts to ignore list |
PUBLISHING_SETUP_SUMMARY.md |
Comprehensive setup summary and quick reference guide for the publishing system |
.github/WORKFLOW_DIAGRAM.md |
Visual documentation of the complete CI/CD workflow process |
.github/VERSION_TAG_FORMAT.md |
Documentation clarifying semantic versioning format without "v" prefix |
.github/README.md |
Complete reference documentation for GitHub Actions workflows |
.github/QUICKSTART.md |
Quick start guide for setting up Chrome Web Store publishing |
.github/PUBLISHING_GUIDE.md |
Detailed step-by-step guide for publishing configuration and usage |
.github/CHANGELOG_VERSION_UPDATE.md |
Migration guide documenting the version tag format change |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| echo "✅ Build validation passed" | ||
|
|
||
| - name: Create extension artifact | ||
| uses: actions/upload-artifact@v3 |
There was a problem hiding this comment.
Using deprecated action version. The actions/upload-artifact@v3 action is outdated. Consider upgrading to v4 which has improved performance and features. Version 3 will eventually be deprecated by GitHub.
Update to:
- name: Create extension artifact
uses: actions/upload-artifact@v4
with:
name: extension-build
path: dist/
retention-days: 30| uses: actions/upload-artifact@v3 | |
| uses: actions/upload-artifact@v4 |
| run: npm run test:coverage | ||
|
|
||
| - name: Upload coverage reports | ||
| uses: codecov/codecov-action@v3 |
There was a problem hiding this comment.
Using deprecated action version. The codecov/codecov-action@v3 is outdated. The latest version is v4 which includes improvements and security updates.
Update to:
- name: Upload coverage reports
uses: codecov/codecov-action@v4
if: always()
with:
fail_ci_if_error: falseNote: v4 may require a Codecov token for private repositories.
| uses: codecov/codecov-action@v3 | |
| uses: codecov/codecov-action@v4 |
| # Get current version from package.json | ||
| CURRENT_VERSION=$(node -p "require('./package.json').version") |
There was a problem hiding this comment.
Missing Node.js installation check. The script uses node -p to read versions from JSON files but doesn't verify that Node.js is installed. If Node.js is not available, the error message will be cryptic.
Add a check at the beginning:
# Check for required commands
if ! command -v node &> /dev/null; then
echo -e "${RED}Error: Node.js is not installed${NC}"
echo "Please install Node.js to use this script"
exit 1
fi| MAJOR="${VERSION_PARTS[0]}" | ||
| MINOR="${VERSION_PARTS[1]}" | ||
| PATCH="${VERSION_PARTS[2]}" | ||
|
|
There was a problem hiding this comment.
The script doesn't handle version strings that might have additional content after the PATCH number. For example, if package.json has a version like "1.0.0-beta" or if there's trailing whitespace, the IFS split and array access could produce unexpected results or empty values. The PATCH variable might contain -beta which would cause arithmetic errors on line 67.
Add validation after splitting:
IFS='.' read -r -a VERSION_PARTS <<< "$CURRENT_VERSION"
MAJOR="${VERSION_PARTS[0]}"
MINOR="${VERSION_PARTS[1]}"
PATCH="${VERSION_PARTS[2]}"
# Validate numeric values
if ! [[ "$MAJOR" =~ ^[0-9]+$ ]] || ! [[ "$MINOR" =~ ^[0-9]+$ ]] || ! [[ "$PATCH" =~ ^[0-9]+$ ]]; then
echo -e "${RED}Error: Current version '$CURRENT_VERSION' is not a valid semantic version${NC}"
exit 1
fi| # Strip any pre-release or build metadata from PATCH (e.g., "0-beta" -> "0") | |
| PATCH="${PATCH%%[^0-9]*}" | |
| # Validate numeric values | |
| if ! [[ "$MAJOR" =~ ^[0-9]+$ ]] || ! [[ "$MINOR" =~ ^[0-9]+$ ]] || ! [[ "$PATCH" =~ ^[0-9]+$ ]]; then | |
| echo -e "${RED}Error: Current version '$CURRENT_VERSION' is not a valid semantic version${NC}" | |
| exit 1 | |
| fi |
| run: | | ||
| echo "✅ Extension published successfully!" | ||
| echo "Version: ${{ github.ref_name }}" | ||
| echo "Extension ID: ${{ secrets.CHROME_EXTENSION_ID }}" |
There was a problem hiding this comment.
Potential information disclosure in logs. The Extension ID is a secret and should not be echoed in workflow logs, even in success messages. While the Extension ID is somewhat less sensitive than credentials, it's still internal information that shouldn't be unnecessarily exposed in public workflow logs.
Remove or redact the Extension ID from logs:
echo "✅ Extension published successfully!"
echo "Version: ${{ github.ref_name }}"
# Remove the following line:
# echo "Extension ID: ${{ secrets.CHROME_EXTENSION_ID }}"| echo "Extension ID: ${{ secrets.CHROME_EXTENSION_ID }}" |
| on: | ||
| push: | ||
| tags: | ||
| - '*.*.*' # Triggers on version tags like 1.0.0, 1.2.3, etc. |
There was a problem hiding this comment.
The tag pattern '*.*.*' is overly broad and will match unintended patterns. It will trigger on tags like a.b.c, foo.bar.baz, or even file-like patterns. This could cause the workflow to run unexpectedly.
Use a more specific pattern to match only semantic version tags:
tags:
- '[0-9]+.[0-9]+.[0-9]+'This ensures only numeric semantic versions trigger the workflow.
| - '*.*.*' # Triggers on version tags like 1.0.0, 1.2.3, etc. | |
| - '[0-9]+.[0-9]+.[0-9]+' # Triggers only on semantic version tags like 1.0.0, 1.2.3, etc. |
|
|
||
| # Update package-lock.json | ||
| echo -e "${BLUE}Updating package-lock.json...${NC}" | ||
| npm install --package-lock-only |
There was a problem hiding this comment.
Missing error handling for npm commands. If npm install --package-lock-only fails (e.g., due to network issues, corrupted package.json, or dependency resolution problems), the script will continue and potentially create an inconsistent state. While set -e is used, npm may return 0 even with warnings that should be errors.
Add explicit error checking:
echo -e "${BLUE}Updating package-lock.json...${NC}"
if ! npm install --package-lock-only; then
echo -e "${RED}Error: Failed to update package-lock.json${NC}"
echo "Please check your package.json for errors"
exit 1
fi| npm install --package-lock-only | |
| if ! npm install --package-lock-only; then | |
| echo -e "${RED}Error: Failed to update package-lock.json${NC}" | |
| echo "Please check your package.json for errors" | |
| exit 1 | |
| fi |
| client-id: ${{ secrets.CHROME_CLIENT_ID }} | ||
| client-secret: ${{ secrets.CHROME_CLIENT_SECRET }} | ||
| refresh-token: ${{ secrets.CHROME_REFRESH_TOKEN }} | ||
| publish: ${{ github.event.inputs.submit_for_review != 'false' }} |
There was a problem hiding this comment.
The publish parameter logic has a type mismatch issue. The input submit_for_review has type: boolean (line 13), which means when manually triggered with the checkbox unchecked, github.event.inputs.submit_for_review will be the boolean false. However, the comparison != 'false' compares against the string 'false', not the boolean.
This means:
- Tag push:
null != 'false'→true(publishes) ✅ - Manual with checkbox checked:
true != 'false'→true(publishes) ✅ - Manual with checkbox unchecked:
false != 'false'→true(still publishes!) ❌
Fix the comparison:
publish: ${{ github.event.inputs.submit_for_review != false }}Or handle both trigger types explicitly:
publish: ${{ github.event_name == 'push' || github.event.inputs.submit_for_review == true }}| publish: ${{ github.event.inputs.submit_for_review != 'false' }} | |
| publish: ${{ github.event.inputs.submit_for_review != false }} |
| #!/bin/bash | ||
|
|
||
| # BaitBreaker Version Bump Script | ||
| # This script updates the version in both package.json and manifest.json | ||
|
|
||
| set -e |
There was a problem hiding this comment.
Missing script execution permission check. The script should verify that it's executable or provide clear instructions if it's not. Users might download this script and forget to make it executable, leading to "Permission denied" errors.
Add a helpful message in the documentation or check permissions:
# At the start of the script, after the shebang
if [ ! -x "$0" ]; then
echo -e "${YELLOW}Note: This script may not be executable.${NC}"
echo "If you get 'Permission denied', run: chmod +x $0"
fiOr document this in the README/setup guide.
| # Update manifest.json | ||
| echo -e "${BLUE}Updating manifest.json...${NC}" | ||
| if command -v jq &> /dev/null; then | ||
| jq ".version = \"$NEW_VERSION\"" manifest.json > manifest.json.tmp && mv manifest.json.tmp manifest.json |
There was a problem hiding this comment.
The jq commands redirect output to a temp file and then move it, which could lead to data loss if the disk is full or if the process is interrupted between creating the temp file and moving it. Additionally, if jq fails (e.g., due to invalid JSON), the original file will be lost.
Add error checking:
if command -v jq &> /dev/null; then
jq ".version = \"$NEW_VERSION\"" manifest.json > manifest.json.tmp || {
echo -e "${RED}Error: Failed to update manifest.json with jq${NC}"
rm -f manifest.json.tmp
exit 1
}
mv manifest.json.tmp manifest.json| jq ".version = \"$NEW_VERSION\"" manifest.json > manifest.json.tmp && mv manifest.json.tmp manifest.json | |
| jq ".version = \"$NEW_VERSION\"" manifest.json > manifest.json.tmp | |
| if [ $? -ne 0 ]; then | |
| echo -e "${RED}Error: Failed to update manifest.json with jq${NC}" | |
| rm -f manifest.json.tmp | |
| exit 1 | |
| fi | |
| # Check that the temp file is non-empty and valid JSON | |
| if [ ! -s manifest.json.tmp ] || ! jq empty manifest.json.tmp &> /dev/null; then | |
| echo -e "${RED}Error: jq produced invalid manifest.json${NC}" | |
| rm -f manifest.json.tmp | |
| exit 1 | |
| fi | |
| # Optionally back up the original file | |
| cp manifest.json manifest.json.bak | |
| mv manifest.json.tmp manifest.json |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (9)
.github/QUICKSTART.md (2)
17-20: Add language specification to fenced code block (MD040).Line 17's code block should specify a language for proper syntax highlighting.
-``` +```bash Go to: https://chrome.google.com/webstore/devconsole Copy from URL: /devconsole/.../YOUR_EXTENSION_ID -``` +```
23-28: Add language specification to fenced code block (MD040).Line 23's code block should specify a language for proper syntax highlighting.
-``` +```bash 1. https://console.cloud.google.com/ 2. APIs & Services → Credentials 3. Create OAuth client ID → Desktop app 4. Save Client ID and Client Secret -``` +```.github/PUBLISHING_GUIDE.md (2)
105-112: Use proper heading instead of emphasis (MD036)."Option A: Tag-based Publishing" should be a heading (
###) instead of bold emphasis for proper document structure.**Option A: Tag-based Publishing** +### Option A: Tag-based Publishing ```bash
122-129: Use proper heading instead of emphasis (MD036)."Option B: Manual Trigger" should be a heading (
###) instead of bold emphasis for proper document structure.**Option B: Manual Trigger** +### Option B: Manual Trigger 1. Go to **Actions** tab in your GitHub repository.github/CHANGELOG_VERSION_UPDATE.md (1)
19-36: Fix unordered list indentation (MD007).List items should have consistent indentation. Nested items should use 2-space indentation from their parent.
### 1. **GitHub Actions Workflow** (`.github/workflows/publish.yml`) - - **Changed:** Tag trigger pattern from `'v*.*.*'` to `'*.*.*'` - - **Effect:** Workflow now triggers on tags like `1.0.0` instead of `v1.0.0` +- **Changed:** Tag trigger pattern from `'v*.*.*'` to `'*.*.*'` +- **Effect:** Workflow now triggers on tags like `1.0.0` instead of `v1.0.0` ### 2. **Version Bump Script** (`scripts/bump-version.sh`) - - **Changed:** Git tag commands now suggest `git tag X.Y.Z` (without "v") - - **Effect:** Script output provides correct tagging commands +- **Changed:** Git tag commands now suggest `git tag X.Y.Z` (without "v") +- **Effect:** Script output provides correct tagging commands ### 3. **Documentation Files** (All `.md` files in `.github/`) - - **Updated Files:** - - `QUICKSTART.md` - - `PUBLISHING_GUIDE.md` - - `README.md` - - `WORKFLOW_DIAGRAM.md` - - `PUBLISHING_SETUP_SUMMARY.md` - - **Changed:** All examples updated to use tags without "v" prefix +- **Updated Files:** + - `QUICKSTART.md` + - `PUBLISHING_GUIDE.md` + - `README.md` + - `WORKFLOW_DIAGRAM.md` + - `PUBLISHING_SETUP_SUMMARY.md` +- **Changed:** All examples updated to use tags without "v" prefixPUBLISHING_SETUP_SUMMARY.md (2)
132-136: Format bare URL as markdown link (MD034).Line 136's URL should be formatted as a markdown link instead of appearing bare.
### Chrome Web Store Dashboard -Check status at: https://chrome.google.com/webstore/devconsole +Check status at: [Chrome Web Store Dashboard](https://chrome.google.com/webstore/devconsole)
201-218: Add language specification to fenced code block (MD040).Line 203's code block should specify a language for proper syntax highlighting.
## 🔍 File Structure -``` +``` .github/ ├── workflows/ │ ├── ci.yml # Continuous Integration │ └── publish.yml # Chrome Web Store Publishing ├── QUICKSTART.md # Quick setup guide ├── PUBLISHING_GUIDE.md # Detailed documentation └── README.md # Workflow reference scripts/ └── bump-version.sh # Version management helper .gitignore # Updated with build artifacts package.json # Added helper scripts -``` +```.github/README.md (1)
70-70: Consider specifying language for ASCII diagram (MD040).While not strictly required for plain text diagrams, adding a language specification can improve rendering in some contexts.
-``` +```text ┌─────────────────────────────────────────────────────────┐scripts/bump-version.sh (1)
81-82: User confirmation implementation requires attention.Line 81 has a potential shell issue: the
readprompt uses$(echo -e ${YELLOW}...)which will interpret the escape sequence at variable expansion time, then again during output. Additionally, the prompt string inside double quotes may not preserve the color codes correctly. Consider simplifying to improve readability and reliability across different shells.-read -p "$(echo -e ${YELLOW}Continue with version bump? [y/N]:${NC} )" -n 1 -r +read -p $'\e[1;33mContinue with version bump? [y/N]:\e[0m ' -n 1 -rThis uses ANSI escape sequences directly without double-processing, making the code more portable.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
.github/CHANGELOG_VERSION_UPDATE.md(1 hunks).github/PUBLISHING_GUIDE.md(1 hunks).github/QUICKSTART.md(1 hunks).github/README.md(1 hunks).github/VERSION_TAG_FORMAT.md(1 hunks).github/WORKFLOW_DIAGRAM.md(1 hunks).github/workflows/ci.yml(1 hunks).github/workflows/publish.yml(1 hunks).gitignore(1 hunks)PUBLISHING_SETUP_SUMMARY.md(1 hunks)package.json(1 hunks)scripts/bump-version.sh(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.8)
.github/workflows/ci.yml
42-42: the runner of "codecov/codecov-action@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
75-75: the runner of "actions/upload-artifact@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
.github/workflows/publish.yml
55-55: the runner of "softprops/action-gh-release@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 LanguageTool
.github/VERSION_TAG_FORMAT.md
[grammar] ~31-~31: Did you mean the noun “publishing”?
Context: ...ulation ## GitHub Actions Trigger The publish workflow triggers on tags matching the ...
(PREPOSITION_VERB)
[duplication] ~88-~88: Possible typo: you repeated a word.
Context: ...c file versions first** before creating tags 2. Tags are immutable - once pushed and publi...
(ENGLISH_WORD_REPEAT_RULE)
.github/PUBLISHING_GUIDE.md
[duplication] ~48-~48: Possible typo: you repeated a word.
Context: ...on it and copy the Item ID from the URL - URL format: `https://chrome.google.com/webs...
(ENGLISH_WORD_REPEAT_RULE)
[style] ~173-~173: To form a complete sentence, be sure to include a subject.
Context: ...'Submit for review after upload' ``` - Can be triggered manually from GitHub Actio...
(MISSING_IT_THERE)
.github/CHANGELOG_VERSION_UPDATE.md
[uncategorized] ~21-~21: The official name of this software platform is spelled with a capital “H”.
Context: ...ed ### 1. GitHub Actions Workflow (.github/workflows/publish.yml) - **Changed:...
(GITHUB)
[uncategorized] ~29-~29: The official name of this software platform is spelled with a capital “H”.
Context: ...cumentation Files** (All .md files in .github/) - Updated Files: - `QUIC...
(GITHUB)
[style] ~42-~42: Consider an alternative for the overused word “exactly”.
Context: ...ation 3. Clarity: Version number is exactly what you see in files ## Migration Gui...
(EXACTLY_PRECISELY)
PUBLISHING_SETUP_SUMMARY.md
[uncategorized] ~9-~9: The official name of this software platform is spelled with a capital “H”.
Context: ...ctions Workflows #### CI Workflow (.github/workflows/ci.yml) Runs on every push a...
(GITHUB)
[uncategorized] ~17-~17: The official name of this software platform is spelled with a capital “H”.
Context: ...t archiving #### Publish Workflow (.github/workflows/publish.yml) Automated publi...
(GITHUB)
[uncategorized] ~50-~50: The official name of this software platform is spelled with a capital “H”.
Context: ... 4. Documentation - 📘 QUICKSTART.md - Get started in 10 mi...
(GITHUB)
[uncategorized] ~51-~51: The official name of this software platform is spelled with a capital “H”.
Context: ...n 10 minutes - 📕 PUBLISHING_GUIDE.md - Complete setup...
(GITHUB)
[uncategorized] ~52-~52: The official name of this software platform is spelled with a capital “H”.
Context: ...- Complete setup guide - 📗 README.md - Workflow architecture an...
(GITHUB)
[uncategorized] ~72-~72: The official name of this software platform is spelled with a capital “H”.
Context: ...ailed instructions:** See QUICKSTART.md Section 1 ### Step 2: A...
(GITHUB)
[uncategorized] ~225-~225: The official name of this software platform is spelled with a capital “H”.
Context: ...--------|-------------| | QUICKSTART.md | Fast setup | First-tim...
(GITHUB)
[uncategorized] ~226-~226: The official name of this software platform is spelled with a capital “H”.
Context: ...irst-time setup | | PUBLISHING_GUIDE.md | Detailed guide |...
(GITHUB)
[uncategorized] ~227-~227: The official name of this software platform is spelled with a capital “H”.
Context: ... Detailed guide | Troubleshooting | | .github/README.md | Archite...
(GITHUB)
[uncategorized] ~227-~227: The official name of this software platform is spelled with a capital “H”.
Context: ...| Troubleshooting | | .github/README.md | Architecture | Understandi...
(GITHUB)
[uncategorized] ~265-~265: The official name of this software platform is spelled with a capital “H”.
Context: ...rest! Questions? Check the docs in .github/ directory. Happy Publishing! 🚀 ...
(GITHUB)
🪛 markdownlint-cli2 (0.18.1)
.github/QUICKSTART.md
17-17: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
23-23: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.github/PUBLISHING_GUIDE.md
105-105: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
122-122: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
.github/README.md
70-70: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.github/WORKFLOW_DIAGRAM.md
5-5: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
96-96: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
147-147: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
171-171: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
205-205: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
234-234: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
273-273: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.github/CHANGELOG_VERSION_UPDATE.md
22-22: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
23-23: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
26-26: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
27-27: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
30-30: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
31-31: Unordered list indentation
Expected: 2; Actual: 5
(MD007, ul-indent)
32-32: Unordered list indentation
Expected: 2; Actual: 5
(MD007, ul-indent)
33-33: Unordered list indentation
Expected: 2; Actual: 5
(MD007, ul-indent)
34-34: Unordered list indentation
Expected: 2; Actual: 5
(MD007, ul-indent)
35-35: Unordered list indentation
Expected: 2; Actual: 5
(MD007, ul-indent)
36-36: Unordered list indentation
Expected: 0; Actual: 3
(MD007, ul-indent)
PUBLISHING_SETUP_SUMMARY.md
136-136: Bare URL used
(MD034, no-bare-urls)
203-203: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
267-267: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Agent
🔇 Additional comments (25)
.gitignore (1)
6-9: Gitignore patterns are appropriate.Both additions align with the new packaging and CI workflows:
*.zipfor the build artifact andcoverage/for test output..github/QUICKSTART.md (1)
54-85: Publishing steps are clear and accurate.The tag format (without "v" prefix) is consistently applied, and the commands are correct. Both automated and manual options are well-documented.
.github/PUBLISHING_GUIDE.md (1)
24-97: Credentials setup instructions are comprehensive and clear.The step-by-step guide for obtaining extension ID, OAuth credentials, and refresh token is well-documented and provides both automated and manual paths.
.github/CHANGELOG_VERSION_UPDATE.md (1)
44-66: Migration guidance and new release instructions are clear.The explanation of the format change and practical steps for using the new format are well-documented. The note that old tags continue to work is reassuring.
package.json (2)
12-15: Script design for version management and pre-hooks is solid.The
prebuildhook ensures version consistency before any build, andprepackageensures tests pass before packaging. This prevents shipping mismatched versions or broken code.
11-15: No action required—all version dependencies are properly configured.The
version:checkscript requirements are satisfied:manifest.jsonexists with aversionfield (1.0.0),package.jsoncontains a matching version (1.0.0), and theprebuildhook will execute without issues. The scripts are correctly implemented..github/VERSION_TAG_FORMAT.md (3)
7-21: Tag format examples are correct and well-presented.The contrast between correct (
1.0.0,2.0.0) and incorrect (v1.0.0) formats is clear and helpful.
29-38: GitHub Actions trigger pattern is correct.The
*.*.*pattern correctly matches semantic versioning tags without the "v" prefix.
65-84: Tag management procedures are comprehensive.Coverage of both script-based and manual tagging, plus deletion procedures, gives developers multiple paths forward.
PUBLISHING_SETUP_SUMMARY.md (2)
257-264: Use proper heading instead of emphasis (MD036)."You're All Set!" should be a heading (
##) instead of bold emphasis for proper document structure.-## 🎊 You're All Set! +## 🎊 You're All Set!Note: This is already formatted correctly as a heading. Likely a false positive from the linter.
5-127: Setup summary is comprehensive and well-organized.Clear documentation of what's been set up, next steps, usage examples, and monitoring guidance. The progression from prerequisites to first release is logical and easy to follow.
.github/README.md (4)
68-107: Workflow architecture diagram is clear and helpful.The ASCII diagram effectively shows the relationship between CI and publish workflows, triggered by different events (push vs. tag), and their outputs. This visual aids understanding of the automation flow.
109-119: Secrets table is clear and comprehensive.All required secrets are listed with descriptions and sources for obtaining them. The inclusion of
GITHUB_TOKEN(auto-provided) is helpful context.
130-162: Publishing workflow documentation is thorough.Both standard and alternative (manual dispatch) publishing paths are well-documented with clear step-by-step instructions and correct use of the new tag format (no "v" prefix).
190-236: Troubleshooting section covers common failure scenarios.Clear guidance for CI failures (tests, build, version mismatch), publish failures (auth, upload, tag conflicts), and helpful commands to diagnose and fix issues.
.github/workflows/ci.yml (2)
50-72: Build validation logic is comprehensive.The validation step correctly checks for dist/, manifest.json, and both required bundles. The implementation is solid and covers the critical artifacts.
81-107: Version check job is well‑structured.The version consistency check runs only on PRs and properly extracts and compares versions from both package.json and manifest.json. This ensures version synchronization is caught early.
.github/workflows/publish.yml (3)
3-13: Tag format aligns with PR objectives.The workflow correctly triggers on tags matching the
*.*.*pattern (e.g., 1.0.0), which removes the "v" prefix as intended. The manual workflow_dispatch option provides flexibility for on-demand publishing.
44-52: Verify Chrome Web Store credentials are configured.The workflow requires four GitHub secrets for authentication: CHROME_EXTENSION_ID, CHROME_CLIENT_ID, CHROME_CLIENT_SECRET, and CHROME_REFRESH_TOKEN. Ensure these are properly configured in the repository settings before the first publish attempt.
38-42: ZIP naming uses git ref_name, which is correct for tags.The ZIP file is correctly named using
{{ github.ref_name }}, which will be the tag name (e.g., 1.0.0) when triggered by a tag push. This maintains consistency with the version format.scripts/bump-version.sh (4)
46-46: Version parsing and calculation logic is solid.The regex validation for explicit X.Y.Z format is correct, and the version increment logic properly handles major/minor/patch bumps with appropriate zero-resets.
Also applies to: 51-76
90-106: jq fallback to sed is appropriate.The script correctly prioritizes jq for cleaner JSON updates and falls back to sed when jq is unavailable. Both approaches properly update the version strings, though sed is less robust for complex JSON.
113-122: Version validation after updates is critical.The script validates that both package.json and manifest.json reflect the NEW_VERSION after updates. This ensures consistency and catches partial failures early, which is essential given the sync requirements.
131-145: Next steps guidance is excellent.The output provides clear, step‑by‑step instructions including a shortcut one‑liner for users. This reduces friction and ensures the version bump is properly committed and tagged.
.github/WORKFLOW_DIAGRAM.md (1)
1-330: Documentation is comprehensive and well‑organized.The workflow diagrams clearly illustrate the publishing flow, CI workflow, secret configuration, version management, error handling, and file dependencies. The ASCII visualizations make the automation easy to understand, and the quick reference commands are valuable for developers.
|
|
||
| ```bash | ||
| # Install a helper tool (one-time) | ||
| npm install -g chrome-webstore-upload-cli | ||
|
|
||
| # Or use curl to get the token manually: | ||
| ``` | ||
|
|
||
| **Manual method using curl:** | ||
|
|
||
| ```bash | ||
| # Step 1: Get authorization code | ||
| # Replace YOUR_CLIENT_ID with your actual client ID | ||
| # Visit this URL in your browser: | ||
| https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob | ||
|
|
||
| # Step 2: After authorizing, copy the authorization code from the page | ||
|
|
||
| # Step 3: Exchange the authorization code for a refresh token | ||
| curl "https://accounts.google.com/o/oauth2/token" \ | ||
| -d "client_id=YOUR_CLIENT_ID" \ | ||
| -d "client_secret=YOUR_CLIENT_SECRET" \ | ||
| -d "code=YOUR_AUTHORIZATION_CODE" \ | ||
| -d "grant_type=authorization_code" \ | ||
| -d "redirect_uri=urn:ietf:wg:oauth:2.0:oob" | ||
|
|
||
| # The response will contain your refresh_token - save it! | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
Verify OAuth 2.0 URLs and endpoints are current.
The curl commands and OAuth flow reference specific Google URLs. Please verify these endpoints are still current and match the latest Google authentication documentation.
🌐 Web query:
What are the current Google OAuth 2.0 endpoints for Chrome Web Store API authentication in 2025?
💡 Result:
Current endpoints (2025) for authenticating to the Chrome Web Store API:
-
Google OAuth 2.0 authorization endpoint:
https://accounts.google.com/o/oauth2/v2/auth. [1] -
Google OAuth 2.0 token endpoint (exchange / refresh):
https://oauth2.googleapis.com/token. [1] -
Token revocation endpoint:
https://oauth2.googleapis.com/revoke. [1] -
Token introspection / tokeninfo (info about an access token):
https://oauth2.googleapis.com/tokeninfo. [1] -
Chrome Web Store API base endpoint:
https://chromewebstore.googleapis.com (use the chromewebstore scopes below when requesting tokens). [2]
Typical scope for the Chrome Web Store Publish API:
- https://www.googleapis.com/auth/chromewebstore (and …/auth/chromewebstore.readonly). [2]
Sources: Google OAuth docs and Chrome Web Store API docs. [1][2]
Update OAuth 2.0 endpoints to current Google standards.
The URLs in this guide are outdated:
- Authorization endpoint should use
/v2/auth:https://accounts.google.com/o/oauth2/v2/auth - Token endpoint should use
https://oauth2.googleapis.com/token(notaccounts.google.com)
Update both curl commands to use the correct 2025 Google OAuth endpoints.
🤖 Prompt for AI Agents
In .github/PUBLISHING_GUIDE.md around lines 54 to 81 the OAuth endpoints are
outdated; update the authorization URL to use
https://accounts.google.com/o/oauth2/v2/auth and the token exchange URL to
https://oauth2.googleapis.com/token, replacing the old accounts.google.com
endpoints in the guide and the curl command while preserving the existing
parameters (client_id, client_secret, code, grant_type, redirect_uri) and
examples.
|
|
||
| ## Publishing Flow Visualization | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Add language specifications to all fenced code blocks.
Markdown linting requires language specifications on all fenced code blocks. The ASCII diagrams should use text language, and bash commands should use bash.
Apply these diffs to fix the fenced code block language specifications:
Line 5:
-```
+```textLine 96:
-```
+```textLine 147:
-```
+```textLine 171:
-```
+```textLine 205:
-```
+```textLine 234:
-```
+```textLine 273:
-```
+```textLine 309 (bash section):
-```bash
+```bash(Already correct, no change needed)
Also applies to: 96-96, 147-147, 171-171, 205-205, 234-234, 273-273
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
5-5: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
.github/WORKFLOW_DIAGRAM.md lines 5, 96, 147, 171, 205, 234, 273, 309: several
fenced code blocks are missing language specs; update each opening
triple-backtick to include the appropriate language spec (use ```text for ASCII
diagrams at lines 5, 96, 147, 171, 205, 234, 273 and ensure the bash section at
line 309 is ```bash); make sure only the opening fence is changed to include the
language and leave the block contents unchanged.
| run: npm run test:coverage | ||
|
|
||
| - name: Upload coverage reports | ||
| uses: codecov/codecov-action@v3 |
There was a problem hiding this comment.
Update outdated GitHub Actions versions.
Both the codecov and upload-artifact actions are flagged as using runner versions that are too old to run on GitHub Actions. Update to the latest versions for compatibility and security patches.
Apply this diff:
- - name: Upload coverage reports
- uses: codecov/codecov-action@v3
+ - name: Upload coverage reports
+ uses: codecov/codecov-action@v4- - name: Create extension artifact
- uses: actions/upload-artifact@v3
+ - name: Create extension artifact
+ uses: actions/upload-artifact@v4Also applies to: 75-75
🧰 Tools
🪛 actionlint (1.7.8)
42-42: the runner of "codecov/codecov-action@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
In .github/workflows/ci.yml around lines 42 and 75, the workflow is using
outdated action versions (codecov/codecov-action and actions/upload-artifact).
Update those two "uses:" entries to their current stable major versions (e.g.,
migrate codecov/codecov-action to the latest v4 tag and actions/upload-artifact
to the latest v4 tag or the official current major), replace the old version
strings with the new tags, and run the workflow locally or in a PR to confirm
compatibility and that no inputs changed between versions.
| publish: ${{ github.event.inputs.submit_for_review != 'false' }} | ||
|
|
||
| - name: Create GitHub Release | ||
| uses: softprops/action-gh-release@v1 |
There was a problem hiding this comment.
Update outdated GitHub Actions version.
The softprops/action-gh-release action is flagged as using an old runner version. Update to v2 for compatibility and latest features.
Apply this diff:
- - name: Create GitHub Release
- uses: softprops/action-gh-release@v1
+ - name: Create GitHub Release
+ uses: softprops/action-gh-release@v2📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: softprops/action-gh-release@v1 | |
| uses: softprops/action-gh-release@v2 |
🧰 Tools
🪛 actionlint (1.7.8)
55-55: the runner of "softprops/action-gh-release@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
.github/workflows/publish.yml around line 55: the workflow references
softprops/action-gh-release@v1 which is outdated; update the action reference to
softprops/action-gh-release@v2 to use the latest runner and features, and verify
no inputs/outputs changed in v2 (adjust calling parameters if necessary) then
run the workflow locally or trigger a test release to confirm compatibility.
|
To use Codex here, create an environment for this repo. |
|
Summary
Testing
|
Update version tag format to remove the "v" prefix for consistency and simpler automation.
This change aligns the Git tag format (e.g.,
1.0.0) with the version numbers inpackage.jsonandmanifest.json, simplifying the publishing workflow. All GitHub Actions workflows, thebump-version.shscript, and documentation have been updated to reflect this new format.Summary by CodeRabbit
Release Notes
Documentation
Chores