Assume a project has a parameter called "paramA" with a default value of "defaultValue". Also assume the client name format is set to ${nodename}_${paramA}. If the project is build with the parameter definition "paramA=otherValue" the effective client name resolved will still be <nodename>_defaultValue rather than <nodename>_otherValue as expected. This is because the default project substitutions are made first.
- is related to
-
JENKINS-25559 Missing hash in client names if ClientNameFormat substitution fails
-
- Resolved
-
-
JENKINS-23467 Streamline the variables handling
-
- Resolved
-
[JENKINS-25226] Perforce Plugin Substitutes default Parameter Value instead of actual Parameter Value for client name
Stuart Rowe
added a comment - Thanks, I never got around to looking into it Caused by JENKINS-23467 in 1.3.28.
The issue seems to be a blocker, a noting on Wiki is required
Code changed in jenkins
User: Oleg Nenashev
Path:
src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
http://jenkins-ci.org/commit/perforce-plugin/7fdf8d0d580661cf12c15f054462f15d30cd61b2
Log:
JENKINS-25226] - A direct unit test for the issue
The test checks that the variables substitution works properly for build parameters.
The change also refactors the provisioning of PerforceSCM stubs.
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/plugins/perforce/utils/MacroStringHelper.java
http://jenkins-ci.org/commit/perforce-plugin/7b22e0b18e27941d07269d53b63e3720841944e5
Log:
[FIXED JENKINS-25226] - Resolve environment variables with a highest priority
Other variables (projects, default parameters, etc.) will be used in the case of missing macros.
It should not happen in general, but may appear in buildEnvironment()
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/utils/MacroStringHelper.java
src/test/java/com/synopsys/arc/jenkinsci/plugins/perforce/MacroStringHelperTest.java
src/test/java/hudson/plugins/perforce/PerforceSCMTest.java
http://jenkins-ci.org/commit/perforce-plugin/fe2717138270aa9a927730dfc7b91e1cc9a97495
Log:
Merge pull request #59 from synopsys-arc-oss/Variables_handling_issues
[FIXED JENKINS-25635,JENKINS-25226] - Variables substitution issues
Compare: https://github.com/jenkinsci/perforce-plugin/compare/44c10b2c639c...fe2717138270
Stuart reported that the issue has not been solved for client names.
Reopening the issue
Brent Scriver
added a comment - I have seen this issue in 1.3.29 of the Perforce plugin where the workspace field was set to ${CLIENTSPEC} and the default value for ${CLIENTSPEC} was empty and is populated by incoming parameters from triggering jobs. The client name format for slaves was just ${basename}. 1.3.29 was selecting the default value instead of the incoming value. Downgrading to 1.3.27 addressed my issue.
Brent Scriver
added a comment - I have seen this issue in 1.3.29 of the Perforce plugin where the workspace field was set to ${CLIENTSPEC} and the default value for ${CLIENTSPEC} was empty and is populated by incoming parameters from triggering jobs. The client name format for slaves was just ${basename}. 1.3.29 was selecting the default value instead of the incoming value. Downgrading to 1.3.27 addressed my issue. 
This issue has been caused by a new variables substitution mechanism.
https://github.com/jenkinsci/perforce-plugin/pull/54
I'll handle it