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

BUILD_USER_ID is missing in a downstream job triggered by an upstream job using Generic Cause when using the Build User Vars Plugin

      When using the Build User Vars Plugin in Jenkins, the BUILD_USER_ID parameter is not set in a downstream job if the upstream job was triggered using Generic Cause(gitlab webhook). The downstream job, triggered by the upstream job, does not receive information about the user who initiated the process, causing issues with tracking user actions. Additionally, the logs show Unsupported cause type(s):...

      Steps to Reproduce:

      1. An upstream job (Job A) is triggered via Generic Cause.
      2. Job A triggers a downstream job (Job B).
      3. Job B has the Build User Vars Plugin enabled to capture the BUILD_USER_ID parameter.
      4. Trigger Job A through Generic Cause.
      5. In Job B, the BUILD_USER_ID variable is missing.

      Expected Behavior:
      The BUILD_USER_ID variable should be available in Job B and should contain the ID of the user who initiated Job A, even when triggered through Generic Cause.

      Actual Behavior:
      In Job B, the BUILD_USER_ID variable is missing, despite the Build User Vars Plugin being enabled.

      This issue occurs only in job chains where the upstream job is triggered via Generic Cause.
      If Job A is triggered manually, the BUILD_USER_ID variable is correctly set and available in Job B.

       

          [JENKINS-73699] BUILD_USER_ID is missing in a downstream job triggered by an upstream job using Generic Cause when using the Build User Vars Plugin

          Brendan Holmes added a comment - - edited

          Adding the error text so easier to find this issue:

          Aug 30, 2024 12:10:27 PM WARNING org.jenkinsci.plugins.builduser.BuildUser handleOtherCausesOrLogWarningIfUnhandled
          Unsupported cause type(s): [org.jenkinsci.plugins.gwt.GenericCause@7520e588]
          

          Brendan Holmes added a comment - - edited Adding the error text so easier to find this issue: Aug 30, 2024 12:10:27 PM WARNING org.jenkinsci.plugins.builduser.BuildUser handleOtherCausesOrLogWarningIfUnhandled Unsupported cause type(s): [org.jenkinsci.plugins.gwt.GenericCause@7520e588]

          Brendan Holmes added a comment - - edited

          Error occurs for me in all jobs triggered by the Generic Webhook Trigger plugin. Not just in downstream jobs.

          Is followed by: "An attempt to send an e-mail to empty list of recipients, ignored" and no email is sent.

          Brendan Holmes added a comment - - edited Error occurs for me in all jobs triggered by the Generic Webhook Trigger plugin. Not just in downstream jobs. Is followed by: " An attempt to send an e-mail to empty list of recipients, ignored " and no email is sent.

          I expect we're missing a GWT varsetter

          Brendan Holmes added a comment - I expect we're missing a GWT varsetter

          Fábio Silva added a comment -

          It is indeed possible to add support for GenericCause provided by the generic webhook trigger plugin. By doing so, the logs will no longer show this warning, and variables can be handled accordingly.

          However, the main challenge here is that, as far as I know, GenericCause does not contain any user context indicating who initiated the build. This means that while we can handle GenericCause in the build user vars plugin similarly to how we handle other causes like SCMTriggerCause, we won't be able to populate the BUILD_USER_ID variable with user information.

          nasfy / brendanh would this type of handling be useful for your case?

          Fábio Silva added a comment - It is indeed possible to add support for GenericCause provided by the generic webhook trigger plugin. By doing so, the logs will no longer show this warning, and variables can be handled accordingly. However, the main challenge here is that, as far as I know, GenericCause does not contain any user context indicating who initiated the build. This means that while we can handle GenericCause in the build user vars plugin similarly to how we handle other causes like SCMTriggerCause , we won't be able to populate the BUILD_USER_ID variable with user information. nasfy / brendanh would this type of handling be useful for your case?

          Brendan Holmes added a comment - - edited

          "GenericCause does not contain any user context" - can capture this from the webhook json in a GWT variable. Eg in GitHub, json path for email address is .head_commit.committer.email. Possibly the same in other SCMs:

          pipeline {
            GenericTrigger(
              genericVariables: [
                [key: 'userEmail', value: "\$.head_commit.committer.email"]
              ],
            ... 

           

          Then these (userEmail in above example) become regular groovy vars. Obviously configuring GWT is outside the scope of this plugin. I suppose how to capture user details like this could be captured in plugin docs. Then as long as variables with names that build-user-vars is expecting exist, they'll be handled by this plugin. But docs would have to be maintained if paths change. I've worked around this now, so understand if this is a "won't do".

          Brendan Holmes added a comment - - edited " GenericCause does not contain any user context " - can capture this from the webhook json in a GWT variable. Eg in GitHub, json path for email address is .head_commit.committer.email . Possibly the same in other SCMs: pipeline { GenericTrigger( genericVariables: [ [key: 'userEmail' , value: "\$.head_commit.committer.email" ] ], ...   Then these (userEmail in above example) become regular groovy vars. Obviously configuring GWT is outside the scope of this plugin. I suppose how to capture user details like this could be captured in plugin docs. Then as long as variables with names that build-user-vars is expecting exist, they'll be handled by this plugin. But docs would have to be maintained if paths change. I've worked around this now, so understand if this is a "won't do".

          So, we're talking about this:

          WARNING org.jenkinsci.plugins.builduser.BuildUser handleOtherCausesOrLogWarningIfUnhandled
          Unsupported cause type(s): [org.jenkinsci.plugins.gwt.GenericCause@3d3decaa]
          

          where GenericCause is provided by the generic webhook trigger plugin.

          I would be happy for the build user vars plugin just to treat this like any other build where there is no triggering user, which I presume is to set the variables to an empty string. Think of how it handles jobs triggered by a timer, or by some other webhook.
          That stops the logs being polluted with WARNINGs.

          brendanh in the previous comment suggested that the GWT could simply pass some "user" details by setting some variables with special names that the BUV plugin looks for.

          It's an interesting idea, although it seems to me somewhat of a hacky solution, and in any case, the downstream jobs could always reference those specially named variables directly.

          zedasvacas I would vote for just updating BVP to know about and handle org.jenkinsci.plugins.gwt.GenericCause, and not to log a warning.

          Matthew Webber added a comment - So, we're talking about this: WARNING org.jenkinsci.plugins.builduser.BuildUser handleOtherCausesOrLogWarningIfUnhandled Unsupported cause type(s): [org.jenkinsci.plugins.gwt.GenericCause@3d3decaa] where GenericCause is provided by the generic webhook trigger plugin. I would be happy for the build user vars plugin just to treat this like any other build where there is no triggering user, which I presume is to set the variables to an empty string. Think of how it handles jobs triggered by a timer, or by some other webhook. That stops the logs being polluted with WARNINGs. brendanh in the previous comment suggested that the GWT could simply pass some "user" details by setting some variables with special names that the BUV plugin looks for. It's an interesting idea, although it seems to me somewhat of a hacky solution, and in any case, the downstream jobs could always reference those specially named variables directly. zedasvacas I would vote for just updating BVP to know about and handle org.jenkinsci.plugins.gwt.GenericCause, and not to log a warning.

            zedasvacas Fábio Silva
            nasfy Ana
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: