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)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.580.3
      perforce plugin 1.3.33
      Environment Injector (EnvInject) plugin 1.90
    • Similar Issues:

      Description

      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)

        Attachments

          Activity

          Hide
          oleg_nenashev 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?

          Show
          oleg_nenashev 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?
          Hide
          calebmayeux 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.

          Show
          calebmayeux 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.
          Hide
          calebmayeux Caleb Mayeux added a comment -

          User configuration error, not a defect.

          Show
          calebmayeux Caleb Mayeux added a comment - User configuration error, not a defect.
          Hide
          peter_liu peter liu added a comment -

          Hi Oleg Nenashev Caleb Mayeux, 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?

          Show
          peter_liu peter liu added a comment - Hi Oleg Nenashev Caleb Mayeux , 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?
          Hide
          cmayeux 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

          Show
          cmayeux 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
          Hide
          peter_liu peter liu added a comment -

          thanks for the quick response, Caleb Mayeux. 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.

          Show
          peter_liu peter liu added a comment - thanks for the quick response, Caleb Mayeux . 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.
          Hide
          peter_liu 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

          Show
          peter_liu 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
          Hide
          oleg_nenashev 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.

          Show
          oleg_nenashev 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.

            People

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

              Dates

              • Created:
                Updated: