Search

I'd like the build scripts to see the actor parameter of the webhook event payload, i.e. who is the user whose actions triggered the build. This is not always the same as the author or committer that can be queried from Git.

Any update when/if this will get implemented?

We need this in order to set up email notifications to users who triggered the build, otherwise the Email Extension plugin can only email anyone who committed instead of the user who triggered the build - https://stackoverflow.com/questions/37567901/setting-jenkins-to-email-a-build-notification-to-the-bitbucket-user-who-pushed-a

Also, I see there is an existing environment variable called 'BUILD_CAUSE', and the value is always 'BITBUCKETWEBHOOKTRIGGERCAUSE' . I think the intention was to give the value of the actor, not the class name. I see in the Messages.Properties file contains this value as a key, and we need it's value or preferably all the actor's attributes instead, the actual class name is useless.

BitbucketWebhookTrigger.displayname=Bitbucket Server trigger build after push
BitbucketWebhookTriggerCause.withAuthor=Triggered by Bitbucket webhook due to changes by {0}.
BitbucketWebhookTriggerCause.withoutAuthor=Triggered by Bitbucket Server webhook.
BitbucketWebhookMultibranchTrigger.displayname=Bitbucket Server trigger scan after push

Scenarios in which this could be useful:

• Preventing inadvertent violations of named-user licensing of build tools.
• Sending email
• Authorize Project plugin setting “Run as the user who triggered the build.” However, implementing this might open a security vulnerability, so I think it is better to exclude this kind of integration until really needed.

The answer on Stack Overflow mentions the BITBUCKET_PAYLOAD environment variable. The Bitbucket plugin adds that in BitbucketPayload.java . Does the Bitbucket Branch Source plugin have anything similar yet?

The X-Hub-Signature header field should not be included in the value of the environment variable. Including it might let someone replay the webhook request and thereby impersonate Bitbucket Server.

Is there a privacy issue if the payload includes the email address and other user information, and this becomes part of a build log? Perhaps it would be safer to make the webhook payload an opt-in feature, enabled with a checkbox in the branch source. If unchecked, Jenkins would not save the payload in the Run and would not add the environment variable.

BitbucketWebhookTriggerCause overrides getShortDescription() to include the display name of the actor from its private BitbucketWebhookTriggerRequest field. Is this already readable via the currentBuild.getBuildCauses('com.atlassian.bitbucket.jenkins.internal.trigger.BitbucketWebhookTriggerCause')[0].shortDescription mechanism that was added in JENKINS-54227? I imagine the class could be moved to a non-“internal” package, and then more public methods could be added to let pipeline scripts read properties of the actor. That way, the email address etc. would not end up in environment variables unless the pipeline deliberately places them there. Unfortunately, it would not be compatible with existing pipelines that use BITBUCKET_PAYLOAD.

The BUILD_CAUSE environment variable is apparently added by BuildCauseRetriever in the Environment Injector plugin. I don’t think it makes sense to extend this with structured payload data.

kon Could you please provide an update on this ticket?

mkjkec2005 I am not working on this ticket.

The plugin is maintained by Atlassian and I don't work for Atlassian. This feature (especially the actor information) could be useful for my employer, but not useful enough to spend time on implementing and contributing it.