Skip to content
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

Use new GitHub app in workflows instead of token #10650

Closed
wants to merge 11 commits into from

Conversation

armandgrillet
Copy link
Contributor

This uses the same GitHub app as the one we use in backend-enterprise. This should allow us to stop using the GitHub token we were previously using.

@armandgrillet armandgrillet self-assigned this Feb 14, 2025
@armandgrillet armandgrillet requested a review from a team as a code owner February 14, 2025 13:15
Copy link
Contributor

@dimitarvdimitrov dimitarvdimitrov left a comment

Choose a reason for hiding this comment

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

the backport and helm-weekly-release-pr workflows are also using GH_BOT_ACCESS_TOKEN

- name: Download yq
uses: dsaltares/[email protected]
with:
repo: 'mikefarah/yq'
version: 'tags/v4.30.6'
file: 'yq_linux_amd64'
target: 'bin/yq'
token: ${{ secrets.GITHUB_TOKEN }}
Copy link
Contributor

Choose a reason for hiding this comment

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

For this one, and other similar cases below, do we have any problems with GITHUB_TOKEN, actually? This one is a short-lived token, auto generated by GitHub, only for the life-time of the action's execution (ref GitHub docs).

That is, GH_BOT_ACCESS_TOKEN is the PAT, that we SHOULD to get rid of. The GITHUB_TOKEN IS fine, as it's managed by GitHub, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, we should keep using a GitHub short-lived token in this workflow.

Comment on lines 43 to -27
gh pr review $PR_URL \
--approve -b "**I'm approving** this pull request, since it is a helm release."
env:
PR_URL: ${{github.event.pull_request.html_url}}
GITHUB_TOKEN: ${{secrets.GH_BOT_ACCESS_TOKEN}}
Copy link
Contributor

@narqo narqo Feb 14, 2025

Choose a reason for hiding this comment

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

BTW, today this doesn't work, because grafanabot (the principal of GH_BOT_ACCESS_TOKEN) is trying to approve its own PR 🤖

Do you happen to know if, after we update to a GH app, this will use different principals for opening a PR, and an auto-approval?

@armandgrillet armandgrillet force-pushed the armandgrillet/use-app-in-workflows branch from cbc928a to 12a4edb Compare February 27, 2025 14:14
@narqo
Copy link
Contributor

narqo commented Feb 28, 2025

Dimitar mentioned above, that the backport and helm-weekly-release-pr workflows also rely on the GH_BOT_ACCESS_TOKEN. Do you want to fix them here also?

Comment on lines +132 to +137

# Use the secrets, they will be obfuscated but that way we'll know they're accessible
- name: Echo secrets
run: |
echo "${{ env.APP_ID }}"
echo "${{ env.PRIVATE_KEY }}"
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about this debug. Below (and in other workflows in this PR) we don't use these envs but rely on the step's output. GitHub should obfuscate them, but leaving that feels a little bit dangerous.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes this was only for testing that the value could be fetched, but now doc-validator is just not running.

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.

4 participants