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

Perforce polling and labeling no longer resolves global password macros (regression from 1.3.27)

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • 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)

          Oleg Nenashev added a comment -

          @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?

          Oleg Nenashev added a comment - @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?

          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 added a comment - User configuration error, not a defect.

          peter liu added a comment -

          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?

          peter liu added a comment - 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

          peter liu added a comment -

          thanks for the quick response, calebmayeux. Actually I am using the global username/password for perforce plugin (not the official one), I needed to check "Inject passwords to the build as environment variables" to make the password variables work, but it has the problem that the password variables are not resolved when polling or labeling.

          peter liu added a comment - thanks for the quick response, calebmayeux . Actually I am using the global username/password for perforce plugin (not the official one), I needed to check "Inject passwords to the build as environment variables" to make the password variables work, but it has the problem that the password variables are not resolved when polling or labeling.

          peter liu added a comment -

          I feel like I should reopen this ticket since it's never fixed and still seen with latest release 1.3.36

          peter liu added a comment - I feel like I should reopen this ticket since it's never fixed and still seen with latest release 1.3.36

          Oleg Nenashev added a comment -

          I do not longer have test environment for the Perforce plugin, hence I am unassigning myself. Even if it is still an issue, the best way to resolve it is to implement integration with Credentials plugin & Co.

          Oleg Nenashev added a comment - I do not longer have test environment for the Perforce plugin, hence I am unassigning myself. Even if it is still an issue, the best way to resolve it is to implement integration with Credentials plugin & Co.

            Unassigned Unassigned
            calebmayeux Caleb Mayeux
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: