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

System env not available for polled or triggered jobs

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • None
    • Tested on Windows only.

      System env not available for polled or triggered jobs.

      For example the following Workspace name does not get the hostname, but rather "COMPUTERNAME".

      Workspace name: jenkins-${NODE_NAME}-${JOB_NAME}-${COMPUTERNAME}

      If this job is started by polling or by a trigger, the workspace does not use the system environment variable, and when run, the Description is not updated with the last used change.

      When you use Build Now, it does find the env variable, and updates the Description appropriately.

      $ p4 clients -t -e jenkins-master-Job1*
      Client jenkins-master-Job1-COMPUTERNAME 2016/11/16 11:03:00 root C:\Program Files (x86)\Jenkins\workspace\Job1 ''
      Client jenkins-master-Job1-JK-WIND7-DBG 2016/11/16 10:51:12 root C:\Program Files (x86)\Jenkins\workspace\Job1 'Change:15305 '

      This is true for at least Freestyle and Multi-configuration projects.

          [JENKINS-39798] System env not available for polled or triggered jobs

          Jason Davis added a comment -

          Interesting, I'm kind of surprised you got COMPUTERNAME to resolve at all since system environment variables on the node or master are typically not available to the various plugin configurations used in Jenkins jobs. You can certainly use system environment variables in Shell and .bat build steps, but those are resolved when they run. Are you defining your workspace name in the Perforce job configuration? Also interesting, do you need both node and computername to unique-ify the workspace name? Won't those two values always be the same anyway the jobs on that Jenkins? On the surface, it'd seem job and node would be enough.

          Jason Davis added a comment - Interesting, I'm kind of surprised you got COMPUTERNAME to resolve at all since system environment variables on the node or master are typically not available to the various plugin configurations used in Jenkins jobs. You can certainly use system environment variables in Shell and .bat build steps, but those are resolved when they run. Are you defining your workspace name in the Perforce job configuration? Also interesting, do you need both node and computername to unique-ify the workspace name? Won't those two values always be the same anyway the jobs on that Jenkins? On the surface, it'd seem job and node would be enough.

          Joel Kovisto added a comment -

          FYI, I work for Perforce, and filed this for a customer. I defined it as a "manual" workspace in the p4-plugin interface. The use case given was that he expected to have multiple masters. Perhaps I should have offered some other advice. My Jenkins knowledge is limited.

          "Note that I chose ${COMPUTERNAME} for a particular reason. We currently have a number of build servers (using Cruise Control as the CI tool). In Jenkins terms these would all be considered to be masters. I am attempting to configure jobs so that it is relatively easy to move the jobs between these servers. Using ${NODE_NAME} in this regard for the Manual workspace behavior seems problematic because if I were to move the job to another server (which also has NODE_NAME = master) I think that Perforce would be confused because it thinks that the workspace is already synced."

          Joel Kovisto added a comment - FYI, I work for Perforce, and filed this for a customer. I defined it as a "manual" workspace in the p4-plugin interface. The use case given was that he expected to have multiple masters. Perhaps I should have offered some other advice. My Jenkins knowledge is limited. "Note that I chose ${COMPUTERNAME} for a particular reason. We currently have a number of build servers (using Cruise Control as the CI tool). In Jenkins terms these would all be considered to be masters. I am attempting to configure jobs so that it is relatively easy to move the jobs between these servers. Using ${NODE_NAME} in this regard for the Manual workspace behavior seems problematic because if I were to move the job to another server (which also has NODE_NAME = master) I think that Perforce would be confused because it thinks that the workspace is already synced."

          Jason Davis added a comment -

          Ah OK - thanks for the clarification. In Jenkins, a master really defines a pretty unique node - it's the default name of the agent that is made available on the Jenkins server. Typically you don't want to build on your master agent/server, so folks add extra agents - or nodes - via separate build servers to spread the load and build redundancy. The server then routes the jobs based on labels, etc. you add to the agent/node definitions. Even with multiple masters, which would mean multiple Jenkins servers, it's really kind of a pain have multiple jenkins agents on the same build server - so I would say in 99.99% of the cases, JOB_NAME + NODE_NAME will result in a unique workspace definition name in an organization. And if it didn't, well, then you can just force sync the workspace when the job builds. You kind of have to do that anyway if your workspace is configured in the Jenkins job (which let's you use JOB_NAME, etc.) and/or your build is allowed to float across multiple build servers via labels.

          My two cents, adding support for COMPUTERNAME in the workspace spec via the job definition would be a very low priority enhancement vs. bug, since that's really not standard practice and not something typically possible in the Jenkins job/plugin configuration.

          Jason Davis added a comment - Ah OK - thanks for the clarification. In Jenkins, a master really defines a pretty unique node - it's the default name of the agent that is made available on the Jenkins server. Typically you don't want to build on your master agent/server, so folks add extra agents - or nodes - via separate build servers to spread the load and build redundancy. The server then routes the jobs based on labels, etc. you add to the agent/node definitions. Even with multiple masters, which would mean multiple Jenkins servers, it's really kind of a pain have multiple jenkins agents on the same build server - so I would say in 99.99% of the cases, JOB_NAME + NODE_NAME will result in a unique workspace definition name in an organization. And if it didn't, well, then you can just force sync the workspace when the job builds. You kind of have to do that anyway if your workspace is configured in the Jenkins job (which let's you use JOB_NAME, etc.) and/or your build is allowed to float across multiple build servers via labels. My two cents, adding support for COMPUTERNAME in the workspace spec via the job definition would be a very low priority enhancement vs. bug, since that's really not standard practice and not something typically possible in the Jenkins job/plugin configuration.

          Joel Kovisto added a comment -

          Thanks for the feedback, Jason! I'll pass it on. Joel

          Joel Kovisto added a comment - Thanks for the feedback, Jason! I'll pass it on. Joel

          AFAI understand this scenario, I think the user has created a label called COMPUTERNAME. If his intention is to run the build having job name <

          {NODE_NAME}

          -

          {JOB_NAME}

          -

          {COMPUTERNAME}

          > on a remotely configured server <COMPUTERNAME> then he has to create the node with this label. Else jenkins will not be able to point the value of COMPUTERNAME. This feature is available in jenkins.

          sudharsan chandrababu added a comment - AFAI understand this scenario, I think the user has created a label called COMPUTERNAME. If his intention is to run the build having job name < {NODE_NAME} - {JOB_NAME} - {COMPUTERNAME} > on a remotely configured server <COMPUTERNAME> then he has to create the node with this label. Else jenkins will not be able to point the value of COMPUTERNAME. This feature is available in jenkins.

            Unassigned Unassigned
            jkovisto Joel Kovisto
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: