-
Hey folks, so I was looking at all the various ways that an Action can be triggered on a PR. I *think* that the feature that I need is missing, but wanted to ask first and see if someone solved it. Basically I have a project with a CI Pipeline that needs to run integration tests (currently the project doesn’t use Github Actions to execute). These integration tests need access to some secret variables in order to run, because they’re operating an actual account of a public service. I’d like to be able to create a Github Action that would execute on PRs *with secrets*, but only after I manually inspect the PR to make sure it’s not malicious. E.g. I’d comment on the PR with “Github, ok to test” (or just pressed a button on the PR page) and only then would the Github Action run. There are implementations of this approach in different CI systems [1], [2]. Is something similar to this possible right now? Thanks! [1] https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
You should just be able to attach a workflow to the issue_comment event type (pull requests are internally/by the API also seen as a type of issue object):
Then in your steps, you can do some verification on the comment content and check wheter you are the author. Although the latter probably has no 100% fool-proof way to be verified, depending on your use-case it may be sufficient to do it like that. So, something like (untested pseudo-code):
|
Beta Was this translation helpful? Give feedback.
-
Ah, I didn’t realize that PRs were just issues. I’ll try doing this, thank you very much! |
Beta Was this translation helpful? Give feedback.
-
This works, but I can’t see it in Pull Request checks, on;y in GitHub actions, and only after the merge to master. How can I cause it to be shown in GitHub PR checks? |
Beta Was this translation helpful? Give feedback.
You should just be able to attach a workflow to the issue_comment event type (pull requests are internally/by the API also seen as a type of issue object):
Then in your steps, you can do some verification on the comment content and check wheter you are the author. Although the latter probably has no 100% fool-proof way to be verified, depending on your use-case it may be sufficient to do it like that. So, something like (untested pseudo-code):