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

${hostname} is not being correctly resolved in slave workspace name

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Jenkins server running on Win2k8 server 64bit, 64bit JRE (0 executors)
      6 Jenkins slaves running on Win7 64bit, 64bit JRE (1 executor)
    • Similar Issues:

      Description

      Previously working builds have suddenly stopped being able to resolve ${hostname} for workspace name

      with the following settings in the job cfg
      >> Workspace (client) ms_${hostname}_evo11main
      >> Client name format for slaves ms_${hostname}_evo11main

      previously this resolved to ms_build5pcw7_evo11main
      now it is resolving to ms_43_evo11main
      where 43 is the first part of the machine ip address (43.xx.xx.xx)

      nslookup works find in both directions for jenkins server and slave.

        Attachments

          Activity

          Hide
          richardtaylor Richard Taylor added a comment -

          As there are many possible external issues could could prevent a host name from being returned I would like to suggest a different solution.
          Using the standard jenkin's substitutions for the workspace name would avoid having to get the host name from the system.

          In our case allowing the use of the the predefined NODE_NAME would be a good solution.

          >> Workspace (client) ms_${NODE_NAME}_evo11main
          >> Client name format for slaves ms_${NODE_NAME}_evo11main

          Thanks

          Show
          richardtaylor Richard Taylor added a comment - As there are many possible external issues could could prevent a host name from being returned I would like to suggest a different solution. Using the standard jenkin's substitutions for the workspace name would avoid having to get the host name from the system. In our case allowing the use of the the predefined NODE_NAME would be a good solution. >> Workspace (client) ms_${NODE_NAME}_evo11main >> Client name format for slaves ms_${NODE_NAME}_evo11main Thanks
          Hide
          rpetti Rob Petti added a comment -

          I specifically chose hostname over node name because the node name can contain special characters that perforce doesn't support.

          Please provide your Jenkins and Perforce plugin version numbers, as well as your JRE Versions. Have you made any changes recently (upgrading, etc) that could have instigated this?

          Show
          rpetti Rob Petti added a comment - I specifically chose hostname over node name because the node name can contain special characters that perforce doesn't support. Please provide your Jenkins and Perforce plugin version numbers, as well as your JRE Versions. Have you made any changes recently (upgrading, etc) that could have instigated this?
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Rob Petti
          Path:
          src/main/java/hudson/plugins/perforce/PerforceSCM.java
          src/main/webapp/help/clientNameFormat.html
          http://jenkins-ci.org/commit/perforce-plugin/74e23f16ad9456598c02a37c3e4015352ab96e3e
          Log:
          JENKINS-10334 adding nodename token for slave client names, with a disclaimer

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java src/main/webapp/help/clientNameFormat.html http://jenkins-ci.org/commit/perforce-plugin/74e23f16ad9456598c02a37c3e4015352ab96e3e Log: JENKINS-10334 adding nodename token for slave client names, with a disclaimer
          Hide
          richardtaylor Richard Taylor added a comment -

          Hi,

          jenkins version 1.420 (also confirmed bug after rolling back to 1.418)
          perforce plugin 1.2.8 (also confirmed bug after rolling back to 1.2.7)

          jenkins master jre 1.6.0_26
          jenkins slave jre 1.6.0_20

          This issue only manifested after upgrading but I can not be 100% sure as this build had not been triggered for a few days (due to there being no SCM changes). After discovering the issue I rolled back the upgrades and the problem still occurs. The master and slave both appear to have correct setup and each resolve the host names correctly.

          Thanks
          Rich

          Show
          richardtaylor Richard Taylor added a comment - Hi, jenkins version 1.420 (also confirmed bug after rolling back to 1.418) perforce plugin 1.2.8 (also confirmed bug after rolling back to 1.2.7) jenkins master jre 1.6.0_26 jenkins slave jre 1.6.0_20 This issue only manifested after upgrading but I can not be 100% sure as this build had not been triggered for a few days (due to there being no SCM changes). After discovering the issue I rolled back the upgrades and the problem still occurs. The master and slave both appear to have correct setup and each resolve the host names correctly. Thanks Rich
          Hide
          dogfood dogfood added a comment -

          Integrated in plugins_perforce #118
          JENKINS-10334 adding nodename token for slave client names, with a disclaimer

          Rob Petti :
          Files :

          • src/main/webapp/help/clientNameFormat.html
          • src/main/java/hudson/plugins/perforce/PerforceSCM.java
          Show
          dogfood dogfood added a comment - Integrated in plugins_perforce #118 JENKINS-10334 adding nodename token for slave client names, with a disclaimer Rob Petti : Files : src/main/webapp/help/clientNameFormat.html src/main/java/hudson/plugins/perforce/PerforceSCM.java
          Hide
          rpetti Rob Petti added a comment -

          Determining the hostname using Java is actually a rather complex task, and isn't successful in all cases, even when the native utilities can resolve it fine. Since nothing has changed in the code, I'm guessing something on your network changed that's preventing it from resolving properly.

          Normally I'd just suggest using the ${hash} substitution, since it's the most effective, but I've added the ${nodename} substitution with the disclaimer that it won't always work.

          Show
          rpetti Rob Petti added a comment - Determining the hostname using Java is actually a rather complex task, and isn't successful in all cases, even when the native utilities can resolve it fine. Since nothing has changed in the code, I'm guessing something on your network changed that's preventing it from resolving properly. Normally I'd just suggest using the ${hash} substitution, since it's the most effective, but I've added the ${nodename} substitution with the disclaimer that it won't always work.
          Hide
          richardtaylor Richard Taylor added a comment -

          Wow that's quick

          I tested using the hash this afternoon and that does still work, I'm guessing that you hash the ip address rather than the hostname?
          It would be good to have documentation about how the hash is generated so that I can decide the risk in using it.
          i.e. is it likely to change without notice? and therefor generate a new workspace and force a full taking sync 4+ hours.

          We rather not use a hash for a couple of reasons.

          1) having hostname in the workspace name tell us where this workspace is being used. With a hash in the name you need to trawl through logs to see there the workspace was used last.
          2) our workspaces are large, switching from hostname to hash means a new workspace and a full checkout.

          As you say resolving hostname is a complex task and has many external dependencies. Using pre-defined jenkins settings feels like a robust solution.

          Many thanks
          Rich

          Show
          richardtaylor Richard Taylor added a comment - Wow that's quick I tested using the hash this afternoon and that does still work, I'm guessing that you hash the ip address rather than the hostname? It would be good to have documentation about how the hash is generated so that I can decide the risk in using it. i.e. is it likely to change without notice? and therefor generate a new workspace and force a full taking sync 4+ hours. We rather not use a hash for a couple of reasons. 1) having hostname in the workspace name tell us where this workspace is being used. With a hash in the name you need to trawl through logs to see there the workspace was used last. 2) our workspaces are large, switching from hostname to hash means a new workspace and a full checkout. As you say resolving hostname is a complex task and has many external dependencies. Using pre-defined jenkins settings feels like a robust solution. Many thanks Rich
          Hide
          rpetti Rob Petti added a comment -

          The hash is based off the node name. We use the hash because it guarantees that there won't be any incompatible characters. You don't have this guarantee when using the straight node name, since the user can define it as whatever they want.

          Show
          rpetti Rob Petti added a comment - The hash is based off the node name. We use the hash because it guarantees that there won't be any incompatible characters. You don't have this guarantee when using the straight node name, since the user can define it as whatever they want.
          Hide
          rpetti Rob Petti added a comment -

          Can't track down the root cause of this issue, since it's very likely environmental in nature. The new ${nodename} substitution should be a sufficient workaround for careful users.

          Show
          rpetti Rob Petti added a comment - Can't track down the root cause of this issue, since it's very likely environmental in nature. The new ${nodename} substitution should be a sufficient workaround for careful users.
          Hide
          ambakshi Amit Bakshi added a comment -

          Why is ${nodename} unsafe? I'm seeing the same issue after upgrading to the latest Jenins + Perforce plugin. ${hostname} comes up as UNKNOWN. Master running on Ubuntu 11.04 and slaves all running on Win2k8R2. Everything on a windows domain w/ AD. Doing a nslookup from the master resolves the hostnames fine.

          Show
          ambakshi Amit Bakshi added a comment - Why is ${nodename} unsafe? I'm seeing the same issue after upgrading to the latest Jenins + Perforce plugin. ${hostname} comes up as UNKNOWN. Master running on Ubuntu 11.04 and slaves all running on Win2k8R2. Everything on a windows domain w/ AD. Doing a nslookup from the master resolves the hostnames fine.
          Hide
          rpetti Rob Petti added a comment -

          As I mentioned, the node name can contain characters that are not valid characters for use with perforce, that's why ${hash} is the default.

          Getting the hostname from Java is tricky business. The perforce plugin uses the function provided by Jenkins core, which does a pretty good job most of the time. If it's not working, then it's likely environmental, or a problem with core.

          Show
          rpetti Rob Petti added a comment - As I mentioned, the node name can contain characters that are not valid characters for use with perforce, that's why ${hash} is the default. Getting the hostname from Java is tricky business. The perforce plugin uses the function provided by Jenkins core, which does a pretty good job most of the time. If it's not working, then it's likely environmental, or a problem with core.

            People

            • Assignee:
              rpetti Rob Petti
              Reporter:
              richardtaylor Richard Taylor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: