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

this.binding.jenkinsProject not returning project of current build

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: active-choices-plugin
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      Using active choice plugin, active choices reactive reference paramter with a scriptler script.

      We are trying to get the current build's SCM repo in order to pull the latest tags. We use

      scm = this.binding.jenkinsProject.scm;
      if (scm instanceof hudson.plugins.git.GitSCM) {
        for (RemoteConfig cfg : scm.getRepositories()) {
          for (URIish uri : cfg.getURIs()) {
            repo = uri.toString();
          }
        }
      }
      println repo
      ...
      

      It should be noted that both

      this.binding.jenkinsProject.scm
      

      and

      jenkinsProject.scm
      

      produce the same results.

      To get the current build and get the repo url. This seems to only return the project that was last saved in the UI, regardless of which job is being run.

      Steps to reproduce:

      1. Create Job A. Include the reactive reference parameter and use the script with the above code. Save it. Build with parameters. In catalina.out on the master Jenkins node, we see the correct repo is being used.

      2. Create Job B. Include the reactive reference parameter and use the script above. Save it.

      3. In Job A: Build with parameters. catalina.out shows the repo from Job B.

      4. Save Job A. Build with parameters. catalina.out shows the repo from Job A.

      5. Create Job C. Do not include reactive reference parameter. Save.

      6. Job A: Build with parameters. catalina.out shows repo from Job A (last job saved in the UI that uses reactive reference parameter.

      If Job X uses the reactive reference parameter, when Job X is saved, any other jobs that also use the reactive reference parameter will return Job X for this.binding.jenkinsProject, or just jenkinsProject (without prepending this.binding)

      Unless I am incorrect in my understanding of how this functions, I would expect

      this.binding.jenkinsProject
      

      to return the current job, not the last one saved in the UI.

      I did see https://issues.jenkins-ci.org/browse/JENKINS-29476 which appears to be related, but not quite the same. jenkinsProject is available after a fresh Jenkins start (as noted in the resolution of that issue), but it just isn't using the project for the currently running build.

      Full script is attached for reference.

        Attachments

          Activity

          Hide
          kinow Bruno P. Kinoshita added a comment -

          Oh, haven't tried to reproduce, but while reading the (great and clear, by the way) issue description, I think it's indeed a bug.

          Not sure how that could be fixed now, but quite interesting. Will try to include it in the next release. Thanks for reporting!

          Show
          kinow Bruno P. Kinoshita added a comment - Oh, haven't tried to reproduce, but while reading the (great and clear, by the way) issue description, I think it's indeed a bug. Not sure how that could be fixed now, but quite interesting. Will try to include it in the next release. Thanks for reporting!
          Hide
          kinow Bruno P. Kinoshita added a comment -

          Issue confirmed locally.

          Show
          kinow Bruno P. Kinoshita added a comment - Issue confirmed locally.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Bruno P. Kinoshita
          Path:
          src/main/java/org/biouno/unochoice/AbstractScriptableParameter.java
          src/main/java/org/biouno/unochoice/DynamicReferenceParameter.java
          http://jenkins-ci.org/commit/active-choices-plugin/1ade075291bd58b9f068cb5f3d9cf03a7bd00f86
          Log:
          [FIXED JENKINS-34988] Remove duplicate code from DynamicReferenceParameter, use code from Abstract parent class (avoids using Descriptor, scans Jenkins objects instead)

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Bruno P. Kinoshita Path: src/main/java/org/biouno/unochoice/AbstractScriptableParameter.java src/main/java/org/biouno/unochoice/DynamicReferenceParameter.java http://jenkins-ci.org/commit/active-choices-plugin/1ade075291bd58b9f068cb5f3d9cf03a7bd00f86 Log: [FIXED JENKINS-34988] Remove duplicate code from DynamicReferenceParameter, use code from Abstract parent class (avoids using Descriptor, scans Jenkins objects instead)
          Hide
          kinow Bruno P. Kinoshita added a comment -

          Added in the release notes for the next release already.

          The DynamicReferenceParameter had some code very similar to the code in the parent class. But while the parent class scanned Jenkins items to find the project, the implementation was looking at the Descriptor object.

          The Descriptor object could vary due to the way objects are persisted in the plug-in, and it is quite brittle and even dangerous rely on that.

          So instead the abstract class is scanning all the items, which can take a bit more, but is safer and more consistent.

          Removed the getParameters method from the DynamicReferenceParameter, leaving the heavy work in the parent class (not in the same method, but actually in getHelperParameters).

          Needs further testing for regressions before/during release.

          Show
          kinow Bruno P. Kinoshita added a comment - Added in the release notes for the next release already. The DynamicReferenceParameter had some code very similar to the code in the parent class. But while the parent class scanned Jenkins items to find the project, the implementation was looking at the Descriptor object. The Descriptor object could vary due to the way objects are persisted in the plug-in, and it is quite brittle and even dangerous rely on that. So instead the abstract class is scanning all the items, which can take a bit more, but is safer and more consistent. Removed the getParameters method from the DynamicReferenceParameter, leaving the heavy work in the parent class (not in the same method, but actually in getHelperParameters). Needs further testing for regressions before/during release.
          Hide
          kinow Bruno P. Kinoshita added a comment -

          Included in 1.5.0

          Show
          kinow Bruno P. Kinoshita added a comment - Included in 1.5.0

            People

            Assignee:
            kinow Bruno P. Kinoshita
            Reporter:
            erbrecht Travis Collins
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: