-
Bug
-
Resolution: Fixed
-
Major
-
Master:
RHEL 6.5 64-bit
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Slave: RHEL 6.5 64-bit
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Client: Arch Linux 64-bit
Jenkins 1.651
Active Choices Plug-in 1.4
Running in Tomcat 8.0.28
No reverse proxy
Jenkins installed via RPM
Slave nodes not involved. Groovy script running on master
Client browser: Chromium Version 50.0.2661.102 (64-bit)Master: RHEL 6.5 64-bit java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Slave: RHEL 6.5 64-bit java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Client: Arch Linux 64-bit Jenkins 1.651 Active Choices Plug-in 1.4 Running in Tomcat 8.0.28 No reverse proxy Jenkins installed via RPM Slave nodes not involved. Groovy script running on master Client browser: Chromium Version 50.0.2661.102 (64-bit)
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.
[JENKINS-34988] this.binding.jenkinsProject not returning project of current build
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)
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.
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!