KostyaSha
Request: Trigger cause environment variable
This plugin is sooo much better than the ghprb plugin. Thank you for your work on this.
I've been able to implement some automation I have for PR open, close and comment. One critical piece that is missing is there is no way for me to tell why the job was triggered. For example, I can see the current status of the PR is closed; however, I can't tell if the trigger for this job was from a PR close event, a comment event, or something else. It'd be great if I could just look at a variable named GITHUB_PR_EVENT_TYPE or similar and determine why this job is currently running from within a script.
Thanks. When you have job with single cause that easy, but information maybe incorrect for the case when there are multiple causes and if you combine them with or/and event types.
if there are multiple causes for a single build (I didn't realize that was even possible), maybe the environment variable could be a comma separated string?
it may have multiple but only one will be chosen so you can trust to know the real possible reason
I'm not sure I understand. This plugin utilizes github webhook events. This happens for every single event and there is only 1 cause for each of those different event types. https://developer.github.com/v3/activity/events/types/ For example, Pull request events have the 'action' key which tells us what actually triggered the webhook. Can we not just pass that info along to the build environment via an environment variable?
This plugin utilizes github webhook events. This happens for every single event and there is only 1 cause for each of those different event types.
No. PR may have different rules like skip PR when some label exists, such information and many more isn't available in github hooks, that's why trigger grabs required information from GH to define whether to trigger job. It is also possible to group rules with AND/OR (that will return cause only when underlying causes appear). Or you can have comment + label added + commit added and etc "events" but only first will be the cause.
ahhh. ok. I understand. You're just using the webhook to trigger a lookup of the PR to compare with what's changed compared to what you have stored locally from the last time you checked. Even so, are you saying it's not possible to provide an environment variable with the list of triggers that caused the build?
I have a single job that is triggered for 3 event types: PR open, comment added to PR, and PR closed. When the PR is opened, I have some automation that creates an environment to test the PR. When a comment is added that matches '(?is)create environment', the create environment automation is triggered again, which will essentially rebuild the environment. When a PR is closed, the automation deletes the environment.
I use the GITHUB_PR_STATE environment variable to determine if this is a PR open or PR close event. I use GITHUB_PR_COMMENT_BODY_MATCH to determine if it was triggered by a comment. The problem I have is if someone comments when a PR is closed, my automation sees the PR as closed and will try to delete the environment again.
I thought of adding a second condition for deletion to check if PR is closed AND GITHUB_PR_COMMENT_BODY_MATCH = null; however, during my testing, I noticed that when a PR is closed, it seemed to also generate a new build for every matching comment in the entire PR. For each of those builds that were triggered for reason 'Comment matches to criteria.', the GITHUB_PR_COMMENT_BODY_MATCH variable was null, so it's not something I can trust to help determine if I want to trigger my environment deletion.
The real issue here stems from the fact that the environment variables reflect the current state of the PR, but I have nothing to tell me what changed to trigger this build, such as, was the PR just closed or is this just a comment to a closed PR.
Actually, i just remembered I'm not using GITHUB_PR_COMMENT_BODY_MATCH. It seems to always have a value of 'null' regardless if a comment matched or not. So, right now, I check if GITHUB_PR_STATE = closed. If it is, I run the environment deletion code. If GITHUB_PR_STATE = open, I run the environment creation code. I could find no way to reliably test if the build is running because of a comment match.
GITHUB_PR_COMMENT_BODY_MATCH < should work, but again it may not be the reason of cause when you have more than one "event" check. i.e. pr close first, then comment match second. (Other comments will read later)
PR is closed
!= PR was closed
is may create infinite triggering, that's why it may make sense only in conjunction with AND/OR wrappers.
Actually, i just remembered I'm not using GITHUB_PR_COMMENT_BODY_MATCH. It seems to always have a value of 'null' regardless if a comment matched or not.
Should be true when non comment cause triggered the build.
is may create infinite triggering, that's why it may make sense only in conjunction with AND/OR wrappers.
What do you suggest checking to determine if the PR has been closed since the last build?
Should be true when non comment cause triggered the build.
What do I check to know if this build was triggered because a comment matched the regex I specified?
I know this is a bit old, but I had a similar question. I am trying to trigger on both PR open and on a comment of which the format is [approve ci insert_some_optional_text_here]. This is to emulate an existing CI we are replacing. So the trigger on PR works fine, as does triggering on comment. I can see the body_match if I have text matched, but then I also have no way to just determine the state of "this was caused by a comment, and not a pr open" to differentiate the generic rebuild state vs. pr open
