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

Perforce plugin cannot determine host name of slave

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.354, Perforce plugin 1.0.28
    • Similar Issues:

      Description

      I get many warnings in log saying something like:

      ... PerforceSCM getEffectiveClientName
      WARNING: Could not get hostname for slave <named-slave>

      It obviously knows the name of the slave, but where's it supposed to get the hostname from? Is this not a Perforce issue, but a more general slave issue?
      It happens for both Linux and Windows based slaves.

        Attachments

          Issue Links

            Activity

            Hide
            torbent torbent added a comment -

            Alright, I'll check my settings. If I find blanks, what kind of "something wrong" should I be looking for?

            If I submit a new job with a blank value, what will it become? ${basename}, I presume?

            Show
            torbent torbent added a comment - Alright, I'll check my settings. If I find blanks, what kind of "something wrong" should I be looking for? If I submit a new job with a blank value, what will it become? ${basename}, I presume?
            Hide
            rpetti Rob Petti added a comment -

            Corrupt class files in the plugin installation directory, or even hudson itself are the only things I can think of. There could possibly be something amiss in the code, but it's pretty simple: If it's blank or null, return a sensible default instead. In any case, this problem itself is probably not causing the issue, but may be indicative of a deeper problem with your installation.

            As I mentioned, the default depends on the settings the job had before you upgraded. ${basename} if "Don't Rename Client" was checked, ${basename}${hostname} if "Use Old Client Name" was checked, and ${basename}${hash} otherwise.

            Show
            rpetti Rob Petti added a comment - Corrupt class files in the plugin installation directory, or even hudson itself are the only things I can think of. There could possibly be something amiss in the code, but it's pretty simple: If it's blank or null, return a sensible default instead. In any case, this problem itself is probably not causing the issue, but may be indicative of a deeper problem with your installation. As I mentioned, the default depends on the settings the job had before you upgraded. ${basename} if "Don't Rename Client" was checked, ${basename} ${hostname} if "Use Old Client Name" was checked, and ${basename} ${hash} otherwise.
            Hide
            torbent torbent added a comment -

            I've just upgraded to 1.360 and p4 plugin 1.1.0. As a part of the upgrade I deleted all .hpi files and the extracted subdirectories in 'plugin', as well as the entire 'war' directory of hudson itself. Should be a clean good installation now.
            But I still have the same problem. In fact, it appears to be logged for ALL polling activity (noticed that a couple of days ago, so not just 1.1.0) on slaves.
            I checked all jobs for one of the slaves that it cannot determine the name of. All jobs had ${basename} as their slave client name.
            I'll attach a piece of the log.

            Show
            torbent torbent added a comment - I've just upgraded to 1.360 and p4 plugin 1.1.0. As a part of the upgrade I deleted all .hpi files and the extracted subdirectories in 'plugin', as well as the entire 'war' directory of hudson itself. Should be a clean good installation now. But I still have the same problem. In fact, it appears to be logged for ALL polling activity (noticed that a couple of days ago, so not just 1.1.0) on slaves. I checked all jobs for one of the slaves that it cannot determine the name of. All jobs had ${basename } as their slave client name. I'll attach a piece of the log.
            Hide
            torbent torbent added a comment -

            Roughly two minutes of log (383 lines), showing Perforce problems with determining slave hostnames when polling. Actual slave names have been deleted; it happened on 2 or 3 different slaves. I believe a couple of builds were triggered in this period - they all work fine wrt Perforce.

            Show
            torbent torbent added a comment - Roughly two minutes of log (383 lines), showing Perforce problems with determining slave hostnames when polling. Actual slave names have been deleted; it happened on 2 or 3 different slaves. I believe a couple of builds were triggered in this period - they all work fine wrt Perforce.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : rpetti
            Path:
            trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
            http://jenkins-ci.org/commit/31632
            Log:
            [FIXED JENKINS-6257] create a workspace filepath for running GetHostname if none is provided during polling

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/31632 Log: [FIXED JENKINS-6257] create a workspace filepath for running GetHostname if none is provided during polling

              People

              • Assignee:
                rpetti Rob Petti
                Reporter:
                torbent torbent
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: