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

          Hide
          scottmarmit Scott Armit added a comment -

          +1 for fixing this. A simple example for why the promote plugin should have the ability to tie to the same node where the build was executed is the Git publisher plugin which is an option in the list of tasks available to the promote plugin. If you want to treat merging/publishing a Git branch or tag created by your build up to the server (which is the point of the Git publisher plugin), then you need access to the workspace of the build.

          Another example is running a script as part of a promotion, and that script is in the workspace/git repository. Sure, you treat the script as a build artifact, then grab it, etc. etc., but it makes a lot more sense to be able to tie a promotion to the same system.

          Thanks for considering.

          Show
          scottmarmit Scott Armit added a comment - +1 for fixing this. A simple example for why the promote plugin should have the ability to tie to the same node where the build was executed is the Git publisher plugin which is an option in the list of tasks available to the promote plugin. If you want to treat merging/publishing a Git branch or tag created by your build up to the server (which is the point of the Git publisher plugin), then you need access to the workspace of the build. Another example is running a script as part of a promotion, and that script is in the workspace/git repository. Sure, you treat the script as a build artifact, then grab it, etc. etc., but it makes a lot more sense to be able to tie a promotion to the same system. Thanks for considering.
          Hide
          sethosinoffice Chris Engel added a comment -

          Is it possible to set the Priority up?
          Would be nice, if it is fixed in the near future.

          Show
          sethosinoffice Chris Engel added a comment - Is it possible to set the Priority up? Would be nice, if it is fixed in the near future.
          Hide
          tobiasbertelsen Tobias Bertelsen added a comment -

          I have found a workaround for this bug:

          The way I distribute the workload, is by having a build parameter defining the build node. This node-parameter is called Hostname.
          In the promotion step, you select "Restrict where this promotion process can be run" and put "$Hostname" (no quotes) in the field "Label Expression."

          Again: this is a workaround, not a fix. I am surprised that this is not the default behavior and has "low" priority. I cannot see an example where it make much sense to run a promotion, without having access to the build artifacts. So +1 for me as well on fixing this.

          Show
          tobiasbertelsen Tobias Bertelsen added a comment - I have found a workaround for this bug: The way I distribute the workload, is by having a build parameter defining the build node. This node-parameter is called Hostname. In the promotion step, you select "Restrict where this promotion process can be run" and put "$Hostname" (no quotes) in the field "Label Expression." Again: this is a workaround, not a fix. I am surprised that this is not the default behavior and has "low" priority. I cannot see an example where it make much sense to run a promotion, without having access to the build artifacts. So +1 for me as well on fixing this.
          Hide
          danielbeck Daniel Beck added a comment -

          I have a lot more experience with Jenkins now, so I realize that I should not rely on workspace files when promoting

          It's sufficient to read the big yellow warning on https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin – it could be rephrased to mention that it could also build on a different node if the original node is busy, but the recommendation is good.

          Show
          danielbeck Daniel Beck added a comment - I have a lot more experience with Jenkins now, so I realize that I should not rely on workspace files when promoting It's sufficient to read the big yellow warning on https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin – it could be rephrased to mention that it could also build on a different node if the original node is busy, but the recommendation is good.
          Hide
          tobiasbertelsen Tobias Bertelsen added a comment -

          Thanks for the comments. I have read a lot more up on it, and I know better understand why the behavior is like it is.

          It's sufficient to read the big yellow warning on https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin

          I don't think it will help to rephrase the warning, since it is in the wrong place. You need that information when you are configurating your promotion, not when you are installing the plugin. The person creating the promotions will most likely never have seen the install page, unless your company has a single person managing all builds on Jenkins and its installation.

          Secondly I don't find the advice to use permalink very useful, since it can only refer to the latest build/promotion. The promotion is tied to a specific build, so it does not make much sense to use artifacts from a newer version of the build.

          I have not been able to find any documentation/guide/tutorial describing this properly, so I decided to write one here. In short: you should set build number to ${PROMOTED_NUMBER} instead of using a permalink, when you copy artifacts.

          Show
          tobiasbertelsen Tobias Bertelsen added a comment - Thanks for the comments. I have read a lot more up on it, and I know better understand why the behavior is like it is. It's sufficient to read the big yellow warning on https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin – I don't think it will help to rephrase the warning, since it is in the wrong place. You need that information when you are configurating your promotion, not when you are installing the plugin. The person creating the promotions will most likely never have seen the install page, unless your company has a single person managing all builds on Jenkins and its installation. Secondly I don't find the advice to use permalink very useful, since it can only refer to the latest build/promotion. The promotion is tied to a specific build, so it does not make much sense to use artifacts from a newer version of the build. I have not been able to find any documentation/guide/tutorial describing this properly, so I decided to write one here . In short: you should set build number to ${PROMOTED_NUMBER} instead of using a permalink, when you copy artifacts.
          Hide
          danielbeck Daniel Beck added a comment -

          I don't think it will help to rephrase the warning, since it is in the wrong place. You need that information when you are configurating your promotion, not when you are installing the plugin.

          My point was that the advice not to rely on the workspace is documented. Sure, it could be placed inside some inline help block, but it exists. As such this can hardly be considered a bug.

          Note that many plugins rely on their wiki page for documentation, since it can be updated without requiring a plugin release, and update by users, and needs not be tied to a specific option. The wiki page of the plugin providing an option is linked from (almost) every inline help block.

          Show
          danielbeck Daniel Beck added a comment - I don't think it will help to rephrase the warning, since it is in the wrong place. You need that information when you are configurating your promotion, not when you are installing the plugin. My point was that the advice not to rely on the workspace is documented. Sure, it could be placed inside some inline help block, but it exists. As such this can hardly be considered a bug. Note that many plugins rely on their wiki page for documentation, since it can be updated without requiring a plugin release, and update by users, and needs not be tied to a specific option. The wiki page of the plugin providing an option is linked from (almost) every inline help block.
          Hide
          sherabi Shez Who added a comment -

          Bamboo doesn't have the concept of promotions, however a secondary build task can be setup to run on the same label and that job would know which node to run on. I would love to see promotions work in the same way i.e. promotions should run on the same node as the one picked out by the label of the build job.
          It is obvious if you have artifacts that only exist on a particular node then the promotions like uploading to hockeyapp should also run on the same node.

          Show
          sherabi Shez Who added a comment - Bamboo doesn't have the concept of promotions, however a secondary build task can be setup to run on the same label and that job would know which node to run on. I would love to see promotions work in the same way i.e. promotions should run on the same node as the one picked out by the label of the build job. It is obvious if you have artifacts that only exist on a particular node then the promotions like uploading to hockeyapp should also run on the same node.
          Hide
          jmellor John Mellor added a comment -

          Can we bump this up in priority and get a fix? Its a royal pain to have to hack around it, since it is normal for the promotion to pick a different server than the build artifacts exist on. Simply forcing the promotion to run on the same machine would resolve most of the angst with this plugin and remove most of the need for the published hack of using the copy-artifact plugin to another host, to work around the real issue.

          My local unix/linux workaround for this issue is to add a stanza to the promotion script to copy the artifacts to the current host. Its not pretty, but it works until this issue gets fixed.

          1. HACK: The artifacts may be on a different build host
            mkdir -p $ARTIFACTS
            PROMOTED_HOST="`echo $PROMOTED_URL | sed 's%^http://(.*):.*%\1%'`"
            scp $PROMOTED_HOST:jobs/$PROMOTED_JOB_NAME/builds/$PROMOTED_NUMBER/archive/$ARTIFACTS/* $ARTIFACTS
          Show
          jmellor John Mellor added a comment - Can we bump this up in priority and get a fix? Its a royal pain to have to hack around it, since it is normal for the promotion to pick a different server than the build artifacts exist on. Simply forcing the promotion to run on the same machine would resolve most of the angst with this plugin and remove most of the need for the published hack of using the copy-artifact plugin to another host, to work around the real issue. My local unix/linux workaround for this issue is to add a stanza to the promotion script to copy the artifacts to the current host. Its not pretty, but it works until this issue gets fixed. HACK: The artifacts may be on a different build host mkdir -p $ARTIFACTS PROMOTED_HOST="`echo $PROMOTED_URL | sed 's%^ http://(.*):.*%\1% '`" scp $PROMOTED_HOST:jobs/$PROMOTED_JOB_NAME/builds/$PROMOTED_NUMBER/archive/$ARTIFACTS/* $ARTIFACTS

            People

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

              Dates

              • Created:
                Updated: