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!