trigger: expose triggering comment ID and URL in JOB_SPEC#770
Conversation
Parsing arguments out of a command (e.g. "/test <args>") is currently unreliable for jobs: a job only receives the PR refs, not the comment that triggered it. Reconstructing the comment from the PR number alone is racy - concurrent or edited /test comments resolve to the wrong body, and UI reruns have no comment at all. This captures the triggering comment in ProwJobSpec via a new optional trigger_comment object and surfaces it to comment-triggered presubmits as two env vars: TRIGGER_COMMENT_ID - numeric GitHub comment ID TRIGGER_COMMENT_URL - full HTML URL to the comment Both are also available in the JSON-encoded JOB_SPEC under trigger_comment.id / trigger_comment.html_url. The comment ID is a stable, unique reference to the exact comment that triggered the run, so a job can fetch its body via the GitHub API directly. The URL also enables a clickable link in reports or distinguishing a manual rerun from an automatic one. The field uses omitempty and is nil for jobs triggered automatically (PR open/update, Tide, periodics), so this is fully backward compatible.
✅ Deploy Preview for k8s-prow ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
|
Welcome @tiborv! |
|
Hi @tiborv. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubernetes-prow
Bot
added
needs-ok-to-test
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: tiborv The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
the
area/documentation
kubernetes-prow
Bot
requested review from
MadhavJivrajani,
Priyankasaggu11929 and
stevekuznetsov
kubernetes-prow
Bot
added
area/plugins
It's not unreliable, it's a hack at best. We actively did not want presubmits with manually supplied arguments to exist in Prow, so I'm not too keen about enabling it through coupling job workloads with trigger comments. |
If the concern is primarily about the indeterminism of job triggers if args are parsed dynamically, can I instead just try to surface more metadata about the trigger event in general? E.g. TRIGGER_EVENT_TYPE=IssueCommentEvent, TRIGGER_EVENT_ID, TRIGGER_EVENT_URL etc. Or is the goal to actively discourage a job from 'knowing' its specific triggering event entirely? |
2 participants
Parsing arguments out of a command (e.g.
/test <args>) is currently unreliable for jobs: a job only receives the PR refs, not the comment that triggered it. Reconstructing the comment from the PR number alone is racy — concurrent or edited/testcomments resolve to the wrong body, and UI reruns have no comment at all.This captures the triggering comment in
ProwJobSpecvia a new optionaltrigger_commentobject and surfaces it to comment-triggered presubmits as two env vars:TRIGGER_COMMENT_ID— numeric GitHub comment IDTRIGGER_COMMENT_URL— full HTML URL to the commentBoth are also available in the JSON-encoded
JOB_SPECundertrigger_comment.id/trigger_comment.html_url. The comment ID is a stable, unique reference to the exact comment that triggered the run, so a job can fetch its body via the GitHub API directly. The URL also enables a clickable link in reports or distinguishing a manual rerun from an automatic one.