ci: add release pipelines for iii-lsp and VSCode extension#17
ci: add release pipelines for iii-lsp and VSCode extension#17
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 18 minutes and 48 seconds. ⌛ 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. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughWorkflow enhancements adding CI/CD support for VS Code extension and LSP projects. Changes include new release workflows for Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 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)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
.github/workflows/ci.yml (1)
94-113: Consider renaming job to reflect actual validation scope.The job name says "Lint" but the actual step runs a packaging dry-run (
vsce package --out /dev/null), not linting. Consider renaming to "Package Check" or "Build Check" for clarity. Alternatively, add actual linting (e.g., ESLint) if that's intended.💡 Suggested name change
iii-lsp-vscode: - name: "iii-lsp-vscode: Lint" + name: "iii-lsp-vscode: Package Check" needs: changes🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 94 - 113, The job labeled "iii-lsp-vscode: Lint" is misleading because the step runs a packaging dry-run (`npx `@vscode/vsce` package --out /dev/null`) rather than linting; update the job's name field (the "name" under the iii-lsp-vscode job) to something like "iii-lsp-vscode: Package Check" or "Build/Package Check" to reflect the actual validation, or alternatively add a lint step (e.g., run ESLint) if linting was intended so the name remains accurate..github/workflows/release-lsp.yml (1)
44-53: Prerelease regex may not match all intended patterns.The regex
-([a-z]+)\.[0-9]+$only matches lowercase prerelease labels (e.g.,alpha,beta,rc). If uppercase or mixed-case labels likeRCorAlphaare ever used, they won't be detected as prereleases. This matches the pattern inrelease-vscode.yml, so it's likely intentional, but worth noting for consistency withcreate-tag.ymlwhich only offers lowercase options.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-lsp.yml around lines 44 - 53, The prerelease regex only matches lowercase labels, so update the regex used on VERSION in the elif clause (currently `-([a-z]+)\.[0-9]+$`) to allow mixed/upper-case prerelease tokens (e.g., use a character class like [A-Za-z]+ or an equivalent case-insensitive approach) so values like "RC" or "Alpha" are detected as prereleases; adjust the regex in the release-lsp.yml condition that tests VERSION and keep the dry-run branch unchanged..github/workflows/create-tag.yml (1)
150-159: Consider adding validation for missing version field in package.json.If
.versionis missing from package.json,jq -r '.version'returns the literal string"null"rather than failing. While the providediii-lsp-vscode/package.jsonhas a valid version field, adding explicit validation would make the workflow more robust against future manifest issues.💡 Suggested defensive check
read_node_version() { - jq -r '.version' "$1" + local ver + ver=$(jq -r '.version // empty' "$1") + if [[ -z "$ver" ]]; then + echo "::error::No version field in $1" + exit 1 + fi + echo "$ver" }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/create-tag.yml around lines 150 - 159, The workflow's read_node_version helper can return the literal "null" when package.json lacks .version, so add validation after invoking read_node_version (and similarly for read_cargo_version via MANIFEST_TYPE) to verify the returned current value is non-empty and not "null"; if invalid, emit a clear error via workflow logging and exit non‑zero. Locate the read_node_version function and the branch that sets current (using MANIFEST_TYPE and read_cargo_version/read_node_version) and insert a guard that checks current != "" && current != "null" (or use jq -e to fail fast) and fail the job with a descriptive message if the check fails.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 94-113: The job labeled "iii-lsp-vscode: Lint" is misleading
because the step runs a packaging dry-run (`npx `@vscode/vsce` package --out
/dev/null`) rather than linting; update the job's name field (the "name" under
the iii-lsp-vscode job) to something like "iii-lsp-vscode: Package Check" or
"Build/Package Check" to reflect the actual validation, or alternatively add a
lint step (e.g., run ESLint) if linting was intended so the name remains
accurate.
In @.github/workflows/create-tag.yml:
- Around line 150-159: The workflow's read_node_version helper can return the
literal "null" when package.json lacks .version, so add validation after
invoking read_node_version (and similarly for read_cargo_version via
MANIFEST_TYPE) to verify the returned current value is non-empty and not "null";
if invalid, emit a clear error via workflow logging and exit non‑zero. Locate
the read_node_version function and the branch that sets current (using
MANIFEST_TYPE and read_cargo_version/read_node_version) and insert a guard that
checks current != "" && current != "null" (or use jq -e to fail fast) and fail
the job with a descriptive message if the check fails.
In @.github/workflows/release-lsp.yml:
- Around line 44-53: The prerelease regex only matches lowercase labels, so
update the regex used on VERSION in the elif clause (currently
`-([a-z]+)\.[0-9]+$`) to allow mixed/upper-case prerelease tokens (e.g., use a
character class like [A-Za-z]+ or an equivalent case-insensitive approach) so
values like "RC" or "Alpha" are detected as prereleases; adjust the regex in the
release-lsp.yml condition that tests VERSION and keep the dry-run branch
unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c1c2feb3-e447-4dd8-a266-010f24ce62c0
⛔ Files ignored due to path filters (1)
iii-lsp-vscode/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (7)
.github/workflows/_rust-binary.yml.github/workflows/ci.yml.github/workflows/create-tag.yml.github/workflows/release-lsp.yml.github/workflows/release-vscode.ymliii-lsp-vscode/package.jsonregistry/index.json
1 participant
Summary
iii-lspbinary (cross-platform builds via_rust-binary.yml)iii-lsp-vscodeextension (VS Code Marketplace + OpenVSX)iii-lspandiii-lsp-vscodetocreate-tag.yml(supports both Cargo.toml and package.json manifests)iii-lspto worker registryiii-lsp-vscodeiii-sdkdependency)Required secrets before first release
VSCE_PATOVSX_PATTest plan
iii-lsp, patch bump, dry-run → verify binary buildsiii-lsp, patch bump, real → verify GitHub Releaseiii-lsp-vscode, patch bump, dry-run → verify VSIX packagesiii-lsp-vscode, patch bump, real → verify Marketplace + OpenVSX listingsSummary by CodeRabbit