Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-60340

BitBucket payload information is not injected in the Jenkins build

      Please inject the bitbucket payload information into the jenkins build environment, as other existing plugins are doing

          [JENKINS-60340] BitBucket payload information is not injected in the Jenkins build

          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.

          Kalle Niemitalo added a comment - 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.

          Benzion added a comment -

          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
          

          Benzion added a comment - 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.

          Kalle Niemitalo added a comment - 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.

          Kalle Niemitalo added a comment - 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.

          Kalle Niemitalo added a comment - - edited

          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.

          Kalle Niemitalo added a comment - - edited 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?

          Mohan Krishan Joshi added a comment - kon  Could you please provide an update on this ticket?

          Kalle Niemitalo added a comment - - edited

          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.

          Kalle Niemitalo added a comment - - edited 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.

            Unassigned Unassigned
            javier_rodriguez Javier Rodríguez
            Votes:
            11 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: