-
Bug
-
Resolution: Unresolved
-
Minor
-
Master:
Linux
Slave [winbuilda01]
Windows Server 2008
Slave [winbuilda02]
Windows Server 2008
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!
[JENKINS-15980] Promotion job doesn't execute on the same machine that the build job executed on.
Charles Mathis
created issue -
Charles Mathis
made changes -
| Description |
Original:
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. :( |
New:
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. :( |
Charles Mathis
made changes -
| Environment |
Original:
Master: Linux Slave [webdeva03] Windows Server 2008 Slave [winbuilda01] Windows Server 2008 |
New:
Master: Linux Slave [winbuilda01] Windows Server 2008 Slave [winbuilda02] Windows Server 2008 |
Charles Mathis
made changes -
| Description |
Original:
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. :( |
New:
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. :( |
Charles Mathis
made changes -
| Labels | Original: artifact plugin promoted-builds | New: artifact plugin promoted-builds slave |
Chris Engel
added a comment - Is it possible to set the Priority up?
Would be nice, if it is fixed in the near future. 
Chris Engel
added a comment - Is it possible to set the Priority up?
Would be nice, if it is fixed in the near future. 
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.
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. Charles Mathis
made changes -
| Description |
Original:
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. :( |
New:
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! |
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.
+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.