ci: use deploy key for semantic-release#55
Conversation
Switch from GITHUB_TOKEN to a deploy key for git operations in the release workflow. This allows semantic-release to push release commits and tags while respecting branch protection rules via ruleset bypass.
|
Claude finished @ian-flores's task —— View job Reviewing PR
Review submitted. The change follows established patterns for enabling automated releases with branch protection via deploy keys. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Security Review (Credential Handling)
This change switches from persist-credentials: false to using a deploy key for git operations in the release workflow. This is a common pattern for semantic-release to push commits and tags when branch protection is enabled.
Reviewed:
- ✅ Deploy key stored as a secret (not hardcoded)
- ✅ Uses SSH key authentication rather than embedding tokens
- ✅ PR description confirms ruleset bypass is properly configured
- ✅
GITHUB_TOKENis still used for GitHub API operations (line 68), which is appropriate
Observation:
The package-helm job (line 71) still uses the default checkout without SSH key, but this is correct since it only reads from the repo and doesn't need push access.
LGTM - the change follows established patterns for enabling automated releases with branch protection.
2 participants
Summary
Switch from
GITHUB_TOKENto a deploy key for git operations in the release workflow.Why
This allows semantic-release to push release commits and tags to
mainwhile respecting branch protection rules. The deploy key (semantic-release-team-operator) is configured as a bypass actor in the newmain-protectionruleset.Changes
persist-credentials: falsewithssh-key: ${{ secrets.DEPLOY_KEY }}in checkout stepSetup completed
DEPLOY_KEYsecretTest plan