Skip to content

chore(release): use deploy keys for relese #3013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 8, 2025

Conversation

nkaradzhov
Copy link
Collaborator

main branch is protected and does not allow direct pushes. the release action needs to push.
branch protection rules can be bypassed for people and apps, but not github actions.

one of the workarounds is to use a ruleset in which we set a deploy key

see: https://github.com/orgs/community/discussions/25305\#discussioncomment-10728028

main branch is protected and does not allow direct pushes.
the release action needs to push.
branch protection rules can be bypassed for people and apps, but not
github actions.

one of the workarounds is to use a ruleset in which we set a deploy key

see: https://github.com/orgs/community/discussions/25305\#discussioncomment-10728028
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR configures the release workflow to use a deploy key for SSH-based pushes to a protected main branch.

  • Adds ssh-key input so the checkout action can authenticate via a deploy key
Comments suppressed due to low confidence (1)

.github/workflows/release.yml:26

  • When using an SSH deploy key, it's recommended to disable the default token by setting persist-credentials: false on the checkout step to avoid conflicts between the GITHUB_TOKEN and your SSH key.
          ssh-key: ${{ secrets.RELEASE_KEY }}

@@ -23,6 +23,7 @@ jobs:
uses: actions/checkout@v4
with:
fetch-depth: 0
ssh-key: ${{ secrets.RELEASE_KEY }}
Copy link
Preview

Copilot AI Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding ssh-known-hosts: github.com (or your Git server's host) to validate the SSH host key and prevent man-in-the-middle attacks.

Suggested change
ssh-key: ${{ secrets.RELEASE_KEY }}
ssh-key: ${{ secrets.RELEASE_KEY }}
ssh-known-hosts: github.com

Copilot uses AI. Check for mistakes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a bad idea , but if the public key is always implicitly added :

( from official docs of checkout v4)

# Known hosts in addition to the user and global host key database. The public SSH
# keys for a host may be obtained using the utility `ssh-keyscan`. For example,
# `ssh-keyscan github.com`. The public key for github.com is always implicitly
# added.
ssh-known-hosts: ''

maybe it doesn't make sense

@@ -23,6 +23,7 @@ jobs:
uses: actions/checkout@v4
with:
fetch-depth: 0
ssh-key: ${{ secrets.RELEASE_KEY }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a bad idea , but if the public key is always implicitly added :

( from official docs of checkout v4)

# Known hosts in addition to the user and global host key database. The public SSH
# keys for a host may be obtained using the utility `ssh-keyscan`. For example,
# `ssh-keyscan github.com`. The public key for github.com is always implicitly
# added.
ssh-known-hosts: ''

maybe it doesn't make sense

@nkaradzhov nkaradzhov merged commit d9a6bb3 into redis:master Jul 8, 2025
14 checks passed
@nkaradzhov nkaradzhov deleted the release branch July 8, 2025 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants