Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| name: Notify Slack for RC failure | ||
| needs: release-rc | ||
| if: ${{ always() && github.event_name == 'workflow_dispatch' && needs.release-rc.result == 'failure' }} | ||
| uses: ./.github/workflows/slack-notify.yml | ||
| secrets: inherit | ||
| with: | ||
| title: 'RC Release' | ||
| status: 'failure' | ||
|
|
||
| notify-rc-success: |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 5 days ago
In general, the fix is to add an explicit permissions block to each job that currently relies on default token permissions and grant only the minimal scopes required. For jobs that simply invoke a reusable workflow for Slack notifications, they usually need no repository access, so permissions: {} (no permissions) or, if needed for logging or metadata, permissions: contents: read is typically sufficient.
For this workflow, two jobs lack explicit permissions: notify-rc-failure (line 286 onward) and notify-rc-success (line 296 onward). Both only uses: ./.github/workflows/slack-notify.yml, inherit secrets, and pass some string inputs; nothing here suggests they require any GitHub API write permissions. The least-privilege and clearest fix is to explicitly disable GITHUB_TOKEN permissions for these jobs with permissions: {}. This ensures they do not accidentally gain broader repository access if defaults are read-write or change in the future, without altering their functional behavior.
Concretely:
- In
.github/workflows/publish.yml, undernotify-rc-failure, insert apermissions: {}key alongsidename,needs,if,uses, etc. - Similarly, under
notify-rc-success, insertpermissions: {}.
No imports or additional methods are needed; this is purely a YAML configuration change.
| @@ -287,6 +287,7 @@ | ||
| name: Notify Slack for RC failure | ||
| needs: release-rc | ||
| if: ${{ always() && github.event_name == 'workflow_dispatch' && needs.release-rc.result == 'failure' }} | ||
| permissions: {} | ||
| uses: ./.github/workflows/slack-notify.yml | ||
| secrets: inherit | ||
| with: | ||
| @@ -297,6 +298,7 @@ | ||
| name: Notify Slack for RC success | ||
| needs: release-rc | ||
| if: ${{ github.event_name == 'workflow_dispatch' && needs.release-rc.result == 'success' }} | ||
| permissions: {} | ||
| uses: ./.github/workflows/slack-notify.yml | ||
| secrets: inherit | ||
| with: |
@supabase/auth-js
@supabase/functions-js
@supabase/postgrest-js
@supabase/realtime-js
@supabase/storage-js
@supabase/supabase-js
commit: |
1 participant
Description
What changed?
release-rcjob inpublish.yml+scripts/release-rc.ts) that allows maintainers to publish versioned RC packages (rcdist-tag) from feature branches before merging to masterfeat:commit now produces a minor canary (e.g.2.101.0-canary.0) instead of always bumping patch regardless of commit typegetLastStableTag()andgetArg()helpers intoscripts/utils.ts(previously duplicated inrelease-stable.ts).agents/skills/) for monitor-ci, nx-workspace, nx-generate, nx-import, nx-plugins, nx-run-tasks, and link-workspace-packagesAGENTS.mdwith Nx workspace guidelines for AI agents.gitignoreto exclude.nx/polygraph,.claude/worktrees, and.claude/settings.local.jsondocs/RELEASE.mdto document the RC workflow, canary versioning fix, and updated usage instructionsWhy was this change needed?
The previous release workflow only had canary and stable releases with no intermediate step for validating features on feature branches before merging to master. This made it difficult to dogfood or share pre-release builds of unreleased features without polluting the canary stream.
The canary versioning fix ensures that
feat:commits correctly produce minor canary bumps rather than patch bumps, which was misleading about the nature of the change.Breaking changes
Checklist
<type>(<scope>): <description>npx nx formatto ensure consistent code formattingAdditional notes
The RC workflow is gated to members of
@supabase/adminor@supabase/sdkteams, matching the same authorization used for stable releases. RC changelogs are anchored to the last stable tag so that RC tags never affect the commit range used by future stable or canary releases.