You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For small projects it is fine. But for shared collaborative efforts, the owner of the GH_TOKEN shouldn't be the commiter for every pr-release managed git change.
github apps can also be scoped to a single repo instead of all repo's a developer's personal access token has access to
The text was updated successfully, but these errors were encountered:
I did a bit of research. I think to keep cost down and security up this should be the flow.
You install pr-release as an app on a repo. pr-release requests the exact permissions it needs.
It then redirects you to a setup page. The setup page fetches the app token and asks the end user to add it to their secrets as PRR_TOKEN. They can also optionally provide secrets_write capability and pr-release can do this for them.
pr-release then checks if the repo has installed the token by generating a workflow that does some permission checks via octokit and running it. (yagni)
Then from then on, there's nothing happening serverside, we just have token generation effectively, but everything else runs on the github workflows, but it will read as pr-release making changes not the person who installed the app.
For small projects it is fine. But for shared collaborative efforts, the owner of the GH_TOKEN shouldn't be the commiter for every pr-release managed git change.
github apps can also be scoped to a single repo instead of all repo's a developer's personal access token has access to
The text was updated successfully, but these errors were encountered: