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

Promotion job doesn't execute on the same machine that the build job executed on.

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      My builds are for windows projects, but this issue would be the case with any project I assume.

      I have a build that is using a label, "win", which both winbuilda01 and winbuilda02 are labelled with.

      Sometimes, the build happens on winbuilda01:
      Started by user Charles Mathis
      Building remotely on winbuilda01 in workspace d:\jenkins-slave\workspace\Deployer
      Using remote perforce client: jenkins_deployer--667683261
      [...successfully builds...]
      Notifying upstream projects of job completion
      Finished: SUCCESS

      But the promotion happens on winbuilda02:
      Started by user chmathis
      Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
      Promoting Deployer #173
      [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
      [...unsuccessfully promotes...]
      Notifying upstream projects of job completion
      Finished: FAILURE

      I would expect one of two things:

      1) It to run the promotion on winbuilda01 since it built it on winbuilda01
      or
      2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

      Neither seem to happen.

      Am I missing something? Or is this a bug?

      ---------------------

      The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves.

      ---------------------
      11/24/2014 Edit:
      I have a lot more experience with Jenkins now, so I realize that I should not rely on workspace files when promoting, but rather archive my artifacts, and copy artifacts from a previous build using the Copy Artifacts plugin. That way, no matter where my promotion runs, it'll always copy down the artifacts to the box it runs on.

      While that is the appropriate thing to do, for less experienced users of Jenkins, it's not obvious, so I would suggest that this issue is still relevant, but understand why it is a lower priority. Thanks!

        Attachments

          Activity

          charlie430 Charles Mathis created issue -
          charlie430 Charles Mathis made changes -
          Field Original Value New Value
          Description My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuila01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuila01:

          Started by user Charles Mathis
          Building remotely on winbuila01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuila01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(
          My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuila01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuila01:
          Started by user Charles Mathis
          Building remotely on winbuila01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuila01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(
          charlie430 Charles Mathis made changes -
          Environment Master:
          Linux

          Slave [webdeva03]
          Windows Server 2008

          Slave [winbuilda01]
          Windows Server 2008
          Master:
          Linux

          Slave [winbuilda01]
          Windows Server 2008

          Slave [winbuilda02]
          Windows Server 2008
          charlie430 Charles Mathis made changes -
          Description My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuila01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuila01:
          Started by user Charles Mathis
          Building remotely on winbuila01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuila01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(
          My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuilda01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuilda01:
          Started by user Charles Mathis
          Building remotely on winbuilda01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuilda01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(
          charlie430 Charles Mathis made changes -
          Labels artifact plugin promoted-builds artifact plugin promoted-builds slave
          charlie430 Charles Mathis made changes -
          Description My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuilda01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuilda01:
          Started by user Charles Mathis
          Building remotely on winbuilda01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuilda01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(
          My builds are for windows projects, but this issue would be the case with any project I assume.

          I have a build that is using a label, "win", which both winbuilda01 and winbuilda02 are labelled with.

          Sometimes, the build happens on winbuilda01:
          Started by user Charles Mathis
          Building remotely on winbuilda01 in workspace d:\jenkins-slave\workspace\Deployer
          Using remote perforce client: jenkins_deployer--667683261
          [...successfully builds...]
          Notifying upstream projects of job completion
          Finished: SUCCESS

          But the promotion happens on winbuilda02:
          Started by user chmathis
          Building remotely on winbuilda02 in workspace D:\jenkins-slave\workspace\Deployer
          Promoting Deployer #173
          [Deployer] $ cmd /c call C:\Windows\TEMP\hudson791959618011257982.bat
          [...unsuccessfully promotes...]
          Notifying upstream projects of job completion
          Finished: FAILURE


          I would expect one of two things:

          1) It to run the promotion on winbuilda01 since it built it on winbuilda01
          or
          2) Copy down the build artifacts to winbuilda02 so that it can run the promotion there

          Neither seem to happen.

          Am I missing something? Or is this a bug?

          ---------------------

          The obvious workaround is to set the build to specific box instead of a label so that the build and promotions jobs do not roam, but that defeats the purpose of using slaves. :(

          ---------------------
          11/24/2014 Edit:
          I have a lot more experience with Jenkins now, so I realize that I should not rely on workspace files when promoting, but rather archive my artifacts, and copy artifacts from a previous build using the Copy Artifacts plugin. That way, no matter where my promotion runs, it'll always copy down the artifacts to the box it runs on.

          While that is the appropriate thing to do, for less experienced users of Jenkins, it's not obvious, so I would suggest that this issue is still relevant, but understand why it is a lower priority. Thanks!
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 146782 ] JNJira + In-Review [ 176706 ]

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            charlie430 Charles Mathis
            Votes:
            7 Vote for this issue
            Watchers:
            9 Start watching this issue

              Dates

              Created:
              Updated: