Conversation
| uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 | ||
| with: | ||
| persist-credentials: true |
There was a problem hiding this comment.
🚩 GITHUB_TOKEN vs SSH deploy key: CI triggers on created PRs
With the SSH deploy key removed, the workflow now relies on GITHUB_TOKEN for authentication. A well-known difference is that PRs created using GITHUB_TOKEN do not trigger subsequent GitHub Actions workflows (e.g., CI checks), whereas PRs created via a deploy key or PAT do. However, since the other analogous workflows (update-font-list.yml:17-19, update-npm-audit.yml:17-19) already operate without an SSH key and presumably work fine, this is likely an accepted tradeoff in this repository. If CI checks running automatically on the created i18n/update PR branch are important, this could be a concern.
(Refers to lines 17-20)
Was this helpful? React with 👍 or 👎 to provide feedback.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3760 +/- ##
=======================================
Coverage 81.32% 81.32%
=======================================
Files 620 620
Lines 39086 39086
Branches 6375 6351 -24
=======================================
Hits 31787 31787
Misses 6329 6329
Partials 970 970 ☔ View full report in Codecov by Sentry. |
When a GitHub action creates a PR, GitHub actions don't run on that PR, because GitHub tries to prevent that type of thing (probably in order to prevent infinite actions, and/or security implications).
A workaround for that is to give an action credentials to act on behalf of a user. I attempted to do that when setting up the workflows that open PRs by using an SSH key as the credential when pushing changes, as this is one of the documented methods in the peter-evans/create-pull-request repo.
Unfortunately this was never successful, and I later discovered that closing and reopening the PR was enough to trigger the workflows.
This PR removes an unneeded secret and brings it in line with our other PR-creating workflows. Once merged, I intend to delete the secret from the repo, so no actions can access it.
This change is