Conversation
Review Summary by QodoAdd v3 release workflow with build, test, and publish
WalkthroughsDescription• Add automated v3 release workflow triggered manually from vibe3 branch • Validate branch, build, test, and publish packages to npm • Notify Slack team when release process starts • Generate versions using Lerna with conventional commits Diagramflowchart LR
trigger["Manual Trigger<br/>vibe3 branch"] --> validate["Validate Branch"]
validate --> notify["Notify Slack"]
validate --> build["Build & Upload"]
build --> test["Run Tests"]
test --> release["Release to npm<br/>with v3 tag"]
File Changes1. .github/workflows/release-v3.yml
|
Code Review by Qodo
1. Dry-run blocks publishing
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| name: Validate Branch | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Ensure running on vibe3 | ||
| if: github.ref != 'refs/heads/vibe3' | ||
| run: | | ||
| echo "::error::Release v3 workflow must be triggered from the vibe3 branch. Current branch: ${{ github.ref }}" | ||
| exit 1 | ||
|
|
||
| notify-release-start: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, this issue is fixed by explicitly declaring a minimal permissions: block for the workflow or for individual jobs, instead of inheriting the repository/org defaults. For most workflows that only need to read repository contents, contents: read is a safe baseline; jobs that create releases or otherwise write to the repo can be given the narrower contents: write or specific scopes as needed.
For this workflow, the best minimally-invasive fix is:
- Add a workflow-level
permissions:block settingcontents: readso that all jobs default to read-only access. - Override
permissionsfor thereleasejob, which creates GitHub releases and likely needs to write release data and possibly tags, by settingcontents: write. This grants that job the rights it needs while keeping others restricted. - Place the workflow-level
permissions:block aftername:and beforeon:for clarity and to follow common conventions.
No extra imports or external libraries are needed; this is purely a YAML configuration change inside .github/workflows/release-v3.yml.
| @@ -1,5 +1,8 @@ | ||
| name: Release v3 version | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
|
|
||
| @@ -57,6 +60,8 @@ | ||
| needs: [build, test] | ||
| if: ${{ needs.build.outputs.has_changes == 'true' }} | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.npm_token }} | ||
| steps: |
| name: Notify Slack - Release Started | ||
| needs: validate-branch | ||
| runs-on: ubuntu-latest | ||
| continue-on-error: true | ||
| steps: | ||
| - name: Send Slack notification | ||
| uses: fjogeleit/http-request-action@v1 | ||
| with: | ||
| url: ${{ secrets.SLACK_DEV_TEAM_WEBHOOK_URL }} | ||
| method: "POST" | ||
| contentType: "application/json" | ||
| data: | | ||
| { | ||
| "event": "v3_release_started", | ||
| "actor": "${{ github.actor }}", | ||
| "commit_id": "${{ github.sha }}", | ||
| "workflow": "${{ github.workflow }}", | ||
| "run_url": "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}", | ||
| "commit_url": "${{ github.server_url }}/${{ github.repository }}/commit/${{ github.sha }}" | ||
| } | ||
|
|
||
| build: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, the fix is to explicitly define permissions: for the workflow or for each job, so that the GITHUB_TOKEN has only the privileges required. For most jobs that only need to read repository metadata, contents: read is sufficient; for jobs that need to create releases, tags, or manipulate repository contents, contents: write (and any other specific scopes) should be set explicitly. Defining permissions: at the workflow root applies to all jobs unless overridden.
For this specific file, the simplest least-disruptive fix is:
- Add a root-level
permissions:block limiting defaults for all jobs to read-only:contents: read. - For the
releasejob, which runsyarn lerna version ... --create-release githubusingGH_TOKEN: ${{ secrets.VIBE_GITHUB_TOKEN }}, theGITHUB_TOKENis not directly used; however, release/tag creation commonly requires repository write permissions. To avoid inadvertently breaking behavior if any step or composite action in.github/actions/*relies onGITHUB_TOKEN, we should grantcontents: writeto that particular job. - The other jobs (
validate-branch,notify-release-start,build,test) only need to read repository information and secrets, so they can safely inheritcontents: readfrom the root.
Concretely:
- In
.github/workflows/release-v3.yml, add at the top level (e.g., afteron:) apermissions: contents: readblock. - Inside the
release:job definition, add apermissions:block withcontents: write.
No additional imports or external packages are needed; this is configuration-only.
| @@ -3,6 +3,9 @@ | ||
| on: | ||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| jobs: | ||
| validate-branch: | ||
| name: Validate Branch | ||
| @@ -57,6 +60,8 @@ | ||
| needs: [build, test] | ||
| if: ${{ needs.build.outputs.has_changes == 'true' }} | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.npm_token }} | ||
| steps: |
| name: Build | ||
| needs: validate-branch | ||
| uses: ./.github/workflows/build-and-upload.yml | ||
| secrets: | ||
| npm_token: ${{ secrets.npm_token }} | ||
|
|
||
| test: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, the fix is to explicitly declare permissions for the GITHUB_TOKEN, applying the principle of least privilege. Start with a restrictive default (typically contents: read) at the workflow root so it applies to all jobs, then override per job if a broader permission is actually required (for example, contents: write for a job that creates GitHub releases).
For this specific workflow in .github/workflows/release-v3.yml, the best targeted fix without changing functionality is:
- Add a workflow-level
permissionsblock undername: Release v3 versionthat sets minimal read-only permissions, e.g.:
permissions:
contents: readThis will apply to all jobs by default.
- The
releasejob runsyarn lerna version ... --create-release github, which uses theGITHUB_TOKENto create GitHub releases (write to repository contents/releases). To preserve current behavior, we should grantcontents: writeto that job specifically by adding apermissionsblock underrelease:. This job-specific block overrides the workflow default only for that job; other jobs remain atcontents: read.
No imports or additional methods are required, as this is pure YAML configuration. The main changes are: (1) insert a permissions: section after the workflow name:; (2) insert a permissions: section under the release job, before needs:.
| @@ -1,4 +1,6 @@ | ||
| name: Release v3 version | ||
| permissions: | ||
| contents: read | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| @@ -54,6 +56,8 @@ | ||
|
|
||
| release: | ||
| name: Release | ||
| permissions: | ||
| contents: write | ||
| needs: [build, test] | ||
| if: ${{ needs.build.outputs.has_changes == 'true' }} | ||
| runs-on: ubuntu-latest |
| name: Test | ||
| needs: build | ||
| uses: ./.github/workflows/test.yml | ||
| with: | ||
| has_changes: ${{ needs.build.outputs.has_changes }} | ||
| secrets: | ||
| npm_token: ${{ secrets.npm_token }} | ||
|
|
||
| release: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, the fix is to add an explicit permissions block that follows least‑privilege principles. We can define restrictive default permissions at the top level of the workflow (permissions: under the workflow name / on: block) so they apply to all jobs, and then override them for specific jobs (here, release) that require additional write permissions.
For this workflow, a good, non‑breaking approach is:
- Add a workflow‑level
permissionsblock with read‑only access to contents and packages, which is sufficient for jobs that only read the repo or artifacts (likevalidate-branch,notify-release-start,build, andtest). - Add a job‑level
permissionsblock to thereleasejob that grants the write scopes it clearly needs. Becausereleaserunsyarn lerna version --create-release githuband uses a PAT‑like secret (VIBE_GITHUB_TOKEN) for releases/tags, it almost certainly needs at least:contents: write(tags/commits/releases)pull-requests: writeif it interacts with PRs (conventional release flows often do)- Potentially
issues: writeif it posts to issues; since we don’t see that here, we can omit it to stay minimal.
- The
testjob is the one flagged but is implemented as a reusable workflow call; it likely only needs read access, which will be provided by the workflow‑levelpermissions.
Concretely:
-
Edit
.github/workflows/release-v3.yml. -
After the
on:section, insert:permissions: contents: read packages: read
-
Inside the
releasejob definition, add apermissions:block that overrides the default:permissions: contents: write pull-requests: write
No imports or external libraries are involved; we only adjust YAML configuration inside this workflow file.
| @@ -3,6 +3,10 @@ | ||
| on: | ||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read | ||
| packages: read | ||
|
|
||
| jobs: | ||
| validate-branch: | ||
| name: Validate Branch | ||
| @@ -57,6 +61,9 @@ | ||
| needs: [build, test] | ||
| if: ${{ needs.build.outputs.has_changes == 'true' }} | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
| pull-requests: write | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.npm_token }} | ||
| steps: |
| name: Release | ||
| needs: [build, test] | ||
| if: ${{ needs.build.outputs.has_changes == 'true' }} | ||
| runs-on: ubuntu-latest | ||
| env: | ||
| NODE_AUTH_TOKEN: ${{ secrets.npm_token }} | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| token: ${{ secrets.VIBE_GITHUB_TOKEN }} | ||
| fetch-depth: 0 | ||
| - name: Run Setup | ||
| uses: ./.github/actions/setup | ||
| with: | ||
| npm_token: ${{ secrets.npm_token }} | ||
| - uses: ./.github/actions/git-creds | ||
| - uses: ./.github/actions/download-builds | ||
| - name: Generate new versions | ||
| run: yarn lerna version --exact --conventional-commits --message "Publish [skip ci]" -y --create-release github | ||
| env: | ||
| GH_TOKEN: ${{ secrets.VIBE_GITHUB_TOKEN }} | ||
| - run: yarn config set registry https://registry.npmjs.org/ | ||
| - name: Setup .npmrc for publish | ||
| id: setup-npmrc | ||
| run: echo "//registry.npmjs.org/:_authToken=$NODE_AUTH_TOKEN" > .npmrc | ||
| - name: Publish to npm with v3 dist-tag | ||
| run: yarn lerna publish from-package --dist-tag v3 --dry-run -y | ||
| - name: Remove .npmrc | ||
| if: steps.setup-npmrc.outcome == 'success' | ||
| run: rm .npmrc |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, the fix is to add an explicit permissions block that grants the least privilege required to run this workflow. Since this workflow mostly uses a custom VIBE_GITHUB_TOKEN secret and is triggered manually (workflow_dispatch), a conservative root-level permissions block of contents: read is an appropriate baseline. If specific jobs (like release) require additional write permissions for GITHUB_TOKEN, they can override or extend permissions at the job level; however, based on the visible snippet, release relies on VIBE_GITHUB_TOKEN for tag/release operations, so contents: read at the workflow level should not change functionality.
Concretely, edit .github/workflows/release-v3.yml to add a root-level permissions: section between the on: block and the jobs: block. This will apply to all jobs in this workflow that do not define their own permissions. The new block should be:
permissions:
contents: readNo imports or new methods are needed; this is purely a YAML configuration change to the workflow file.
| @@ -3,6 +3,9 @@ | ||
| on: | ||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| jobs: | ||
| validate-branch: | ||
| name: Validate Branch |
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
| - name: Publish to npm with v3 dist-tag | ||
| run: yarn lerna publish from-package --dist-tag v3 --dry-run -y |
There was a problem hiding this comment.
1. Dry-run blocks publishing 🐞 Bug ✓ Correctness
The v3 release workflow runs yarn lerna publish with --dry-run, so it can succeed without actually publishing any packages to npm. This makes the workflow non-functional as a release pipeline.
Agent Prompt
### Issue description
The v3 release workflow uses `lerna publish ... --dry-run`, which prevents publishing packages to npm.
### Issue Context
This workflow is named and structured as a release workflow, and the existing `release.yml` performs a real publish.
### Fix Focus Areas
- .github/workflows/release-v3.yml[81-82]
### Proposed change
Update the publish step to remove `--dry-run` (keep `--dist-tag v3` if that’s intended), e.g.:
- `yarn lerna publish from-package --dist-tag v3 -y`
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2 participants
https://monday.monday.com/boards/10027056258/pulses/10027056856