-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 1.580.3
perforce plugin 1.3.33
Environment Injector (EnvInject) plugin 1.90
After recently upgrading from 1.3.27 to 1.3.33, job polling appears to be failing with unresolved macro issues trying to poll when using perforce plugin in conjunction with Environment Injector plugin.
I have a global password in the global config. In the job config, I have that variable name, let's say MY_P4PASSWD, set in the field for the perforce password. Also in the job config I have the "Inject passwords to the build as environment variables" and the "Global passwords" box checked under that.
The variable is correctly resolved during the checkout, however no longer resolves during polling or during labeling. It all worked fine in 1.3.27. Also I reverted plugin version and tested that it wasn't any other variable in configuration.
Snippet of stack trace from polling:
FATAL: <${MY_P4PASSWD}>: Found unresolved macro at '${MY_P4PASSWD}'
hudson.plugins.perforce.utils.ParameterSubstitutionException: <${MY_P4PASSWD}>: Found unresolved macro at '${MY_P4PASSWD}'
at hudson.plugins.perforce.utils.MacroStringHelper.checkString(MacroStringHelper.java:154)
at hudson.plugins.perforce.utils.MacroStringHelper.substituteParameters(MacroStringHelper.java:102)
at hudson.plugins.perforce.PerforceSCM.getDecryptedP4Passwd(PerforceSCM.java:2700)
at hudson.plugins.perforce.PerforceSCM.getDepot(PerforceSCM.java:487)
at hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1310)
at hudson.scm.SCM.poll(SCM.java:401)
[JENKINS-26999] Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)
Caleb Mayeux
created issue -
| Assignee | Original: Rob Petti [ rpetti ] | New: Oleg Nenashev [ oleg_nenashev ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Caleb Mayeux
added a comment - @Oleg
Thanks for the quick response!
Wow, I feel pretty stupid. So turns out, it always worked previously because the first time it went to poll, it'd find no prior builds and thus start a build. Subsequently, the polling process would just reuse the ticket acquired from the login of the previous build, never actually relying on the credentials in the job.
When I updated the perforce plugin, I also rebooted the Jenkins instance, for the first time in a very long time, which apparently cleared all the cached tickets, breaking polling across all my jobs. When I reverted the plugin and retried with the old plugin, first I had manually hit some builds, which refreshed the stored tickets, giving the illusion of it working with the old version but not the new version.
Sorry for the misdirection! And yep, you were right that my polling procedures weren't completely correct. Can close as invalid.
Caleb Mayeux
added a comment - @Oleg
Thanks for the quick response!
Wow, I feel pretty stupid. So turns out, it always worked previously because the first time it went to poll, it'd find no prior builds and thus start a build. Subsequently, the polling process would just reuse the ticket acquired from the login of the previous build, never actually relying on the credentials in the job.
When I updated the perforce plugin, I also rebooted the Jenkins instance, for the first time in a very long time, which apparently cleared all the cached tickets, breaking polling across all my jobs. When I reverted the plugin and retried with the old plugin, first I had manually hit some builds, which refreshed the stored tickets, giving the illusion of it working with the old version but not the new version.
Sorry for the misdirection! And yep, you were right that my polling procedures weren't completely correct. Can close as invalid. Caleb Mayeux
added a comment - User configuration error, not a defect. Caleb Mayeux
made changes -
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
Caleb Mayeux
made changes -
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
Hi oleg_nenashev calebmayeux, I am seeing exact the same error with the same plugin versions, how could we hack in EnvInject plugin to inject the password variable to Perforce polling?
Caleb Mayeux
added a comment - Hey Peter,
It's been quite a while since I looked at this, but I remember the issue is that the polling environment doesn't have the full build environment context. Not sure how you would hack the envinject plugin to do that, not to mention the fact that it would generally be unwise to introduce a dependency to the perforce plugin in the envinject plugin.
If you've got Cloudbees support, you can try to use some of their templating features to inject the actual password (encrypted) into the xml of the job config. Otherwise, probably your best bet, if you are mostly just using one set of credentials per Jenkins instance, is to use the global username/password. Alternately you can use the perforce plugin put out by perforce itself, which if I'm not mistaken uses Jenkins credentials (though honestly overall I'm not as keen on that plugin as this one, even though that one is the "official" Jenkins plugin).
Caleb
Caleb Mayeux
added a comment - Hey Peter,
It's been quite a while since I looked at this, but I remember the issue is that the polling environment doesn't have the full build environment context. Not sure how you would hack the envinject plugin to do that, not to mention the fact that it would generally be unwise to introduce a dependency to the perforce plugin in the envinject plugin.
If you've got Cloudbees support, you can try to use some of their templating features to inject the actual password (encrypted) into the xml of the job config. Otherwise, probably your best bet, if you are mostly just using one set of credentials per Jenkins instance, is to use the global username/password. Alternately you can use the perforce plugin put out by perforce itself, which if I'm not mistaken uses Jenkins credentials (though honestly overall I'm not as keen on that plugin as this one, even though that one is the "official" Jenkins plugin).
Caleb
@Caleb
I definitely should check it on my own, because I've never thought such case may work
Build wrappers should not inject variables outside the build in general, but there could be hacks in EnvInject plugin or missed routines in Perforce plugin. On the other hand, in 1.3.27 polling used to ignore missing variables, so probably you polling procedures weren't completely correct..
Have you updated Jenkins core or EnvInject plugin together with Perforce plugin?