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

Perforce plugin does not substitute all variables when polling for new changes

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • Windows 7 Professional 64-Bit, Jenkins 1.471, Winstone servlet engine, Perforce plugin 1.3.17

      The Perforce plugin does not substitute all variables when polling for changes. I use variables in the following fields: "Workspace (client)" and "View Map".
      The plugin replaces only the variable ${JOB_NAME} with the correct value, but ignores ${NODE_NAME} and ${USERNAME} (and perhaps some other variables too). Using %USERNAME% instead of ${USERNAME} does not work.

      The polling log looks like:

      Started on 14.08.2012 16:36:33
      Looking for changes...
      Using node: Jenkins
      Using master perforce client: ${USERNAME}admin.test${NODE_NAME}
      [JENKINS_HOME] $ "c:\Program Files\P4\p4.exe" workspace -o ${USERNAME}admin.test${NODE_NAME}
      [JENKINS_HOME] $ "c:\Program Files\P4\p4.exe" counter change
      [JENKINS_HOME] $ "c:\Program Files\P4\p4.exe" -s changes -s submitted //${USERNAME}admin.test

      {NODE_NAME}

      /...@26326,@26325
      No changes found.

      When I do not use polling (starting the job manually), the plugin has no problem to create and sync the workspace.

          [JENKINS-14787] Perforce plugin does not substitute all variables when polling for new changes

          Rob Petti added a comment -

          What is USERNAME supposed to be set to? That's not a standard Jenkins environment variable.

          Rob Petti added a comment - What is USERNAME supposed to be set to? That's not a standard Jenkins environment variable.

          Rob Petti added a comment -

          Not critical, since polling continues to work despite not replacing these tokens.

          Rob Petti added a comment - Not critical, since polling continues to work despite not replacing these tokens.

          Rob Petti added a comment -

          If you want the node name to be included in client names, then use ${nodename} in the 'client name format for slaves' option.

          Rob Petti added a comment - If you want the node name to be included in client names, then use ${nodename} in the 'client name format for slaves' option.

          What confuses me is the difference between polling and running a job. I would expect that the same variables are substituted in both cases. A list of supported variables for the fields "Perforce/Project Details/Workspace (client)" and "Perforce/Project Details/Client View Type/View Map" would be great.

          The variable ${USERNAME} should be replaced with the user name that is used for connecting to Perforce (field "Perforce/Depot/Username"). Perhaps this variable should be named as ${P4USER}.

          The use of ${nodename} in the 'client name format for slaves' option is a good workaround.

          Bernhard Berbuir added a comment - What confuses me is the difference between polling and running a job. I would expect that the same variables are substituted in both cases. A list of supported variables for the fields "Perforce/Project Details/Workspace (client)" and "Perforce/Project Details/Client View Type/View Map" would be great. The variable ${USERNAME} should be replaced with the user name that is used for connecting to Perforce (field "Perforce/Depot/Username"). Perhaps this variable should be named as ${P4USER}. The use of ${nodename} in the 'client name format for slaves' option is a good workaround.

          Rob Petti added a comment -

          Builds get a full build environment set up for it, and they also have a simple mechanism for extracting those environment variables for substitution. Polling threads have neither. They only exist to run the necessary polling commands, so the environment is pretty bare, and there isn't an easy way to get the environment out of them afaik. Only build parameters, node properties, and global properties are fully supported. Like most other plugins, environment variables are not fully supported in the perforce plugin.

          I can add the substitutions for P4USER, P4PORT, etc explicitly to the substitutions being performed, but that might be the best I can do right now...

          Rob Petti added a comment - Builds get a full build environment set up for it, and they also have a simple mechanism for extracting those environment variables for substitution. Polling threads have neither. They only exist to run the necessary polling commands, so the environment is pretty bare, and there isn't an easy way to get the environment out of them afaik. Only build parameters, node properties, and global properties are fully supported. Like most other plugins, environment variables are not fully supported in the perforce plugin. I can add the substitutions for P4USER, P4PORT, etc explicitly to the substitutions being performed, but that might be the best I can do right now...

          I wasn't aware about the different environments for build and polling. Perhaps it would be a got idea to document this in the wiki?

          Having a substitution for P4User would be sufficient for my needs.

          Bernhard Berbuir added a comment - I wasn't aware about the different environments for build and polling. Perhaps it would be a got idea to document this in the wiki? Having a substitution for P4User would be sufficient for my needs.

          Rob Petti added a comment -

          Generally environment variables are not using in plugin configuration, only build parameters, that's why it's undocumented. Feel free to update it, and I'll see if I can add the substitutions you requested. Granted, P4USER will always be constant, so it shouldn't even need to be defined as a parameter reference in your job configuration.

          Rob Petti added a comment - Generally environment variables are not using in plugin configuration, only build parameters, that's why it's undocumented. Feel free to update it, and I'll see if I can add the substitutions you requested. Granted, P4USER will always be constant, so it shouldn't even need to be defined as a parameter reference in your job configuration.

          Code changed in jenkins
          User: Rob Petti
          Path:
          src/main/java/hudson/plugins/perforce/PerforceSCM.java
          http://jenkins-ci.org/commit/perforce-plugin/901aac98ef2347879aeacabae27035000a897d98
          Log:
          JENKINS-14787 added P4USER as a valid parameter substitution during polling

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/perforce-plugin/901aac98ef2347879aeacabae27035000a897d98 Log: JENKINS-14787 added P4USER as a valid parameter substitution during polling

          Richard Lee added a comment -

          Discussed in another bug, but in case others have run into this issue, P4PASSWD also does not currently appear to be substituted during polling.

          Richard Lee added a comment - Discussed in another bug, but in case others have run into this issue, P4PASSWD also does not currently appear to be substituted during polling.

            Unassigned Unassigned
            bernhardb Bernhard Berbuir
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: