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
Suppose I want to run pronto in my GitHub project's travis CI script. I can add a new stage in my script that is responsible for running pronto. I have two options to provide a github user access token:
In .pronto.yml file, but this has the obvious disadvantage that anybody with access to the project can read my access token and impersonate my automatic code review bot.
As an environment variable in my repository's travis-ci settings. However, this way, pronto won't be able to post comments on pull requests sent from forks, since travis-ci handles these pull requests in a special way for security reasons. I believe that this kind of pull requests is actually the very reason we have pronto. if it was only about reviewing own pull requests, I would rather do local checks before pushing into github. Am I misunderstanding things here?
And even if other CI providers have options to set an environment variable that can be accessed when it is run for pull requests sent from forks, a malicious user might change my .travis.yml file to make it output the access token and impersonate my bot again...
So it seems to me like I either give all users access to my bot's account in one way or another, or I forego automatic code review for forks' pull requests. What am I missing?
P.S. the same exact argument applies to the GitLab CI system
The text was updated successfully, but these errors were encountered:
Suppose I want to run pronto in my GitHub project's travis CI script. I can add a new stage in my script that is responsible for running pronto. I have two options to provide a github user access token:
In
.pronto.yml
file, but this has the obvious disadvantage that anybody with access to the project can read my access token and impersonate my automatic code review bot.As an environment variable in my repository's travis-ci settings. However, this way, pronto won't be able to post comments on pull requests sent from forks, since travis-ci handles these pull requests in a special way for security reasons. I believe that this kind of pull requests is actually the very reason we have pronto. if it was only about reviewing own pull requests, I would rather do local checks before pushing into github. Am I misunderstanding things here?
And even if other CI providers have options to set an environment variable that can be accessed when it is run for pull requests sent from forks, a malicious user might change my
.travis.yml
file to make it output the access token and impersonate my bot again...So it seems to me like I either give all users access to my bot's account in one way or another, or I forego automatic code review for forks' pull requests. What am I missing?
P.S. the same exact argument applies to the GitLab CI system
The text was updated successfully, but these errors were encountered: