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

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

            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: