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