I am experiencing this same bug. If I use the Force Promotion button to promote a build the re-execute promotion button never appears and I have to kick off another build to redo a promotion. This is a pretty serious problem for me.

IMHO, this is coming from:
https://github.com/jenkinsci/promoted-builds-plugin/commit/9395ed5d781ac93fcd6baf629e99a2f0048a05aa

there was a change to src/main/resources/hudson/plugins/promoted_builds/PromotedBuildAction/index.jelly
which introduced a condition

<j:if test="${!p.isManuallyApproved()}">

The manually approved "re-execute" button just moved into the Badge:
https://github.com/jenkinsci/promoted-builds-plugin/blob/9395ed5d781ac93fcd6baf629e99a2f0048a05aa/src/main/resources/hudson/plugins/promoted_builds/conditions/ManualCondition/Badge/index.jelly#L12

The previous re-execute should was preserved for the non-manual promotion (as you pointed out).

Can you provide with more details of the job? what conditions do you have?

I also have this problem. The re-execute promotion option seems to disappear only when I've checked the "only when manually approved" checkbox. If I uncheck that box, the re-execute button reappears.

The manually approved "re-execute" button just moved into the Badge:

Forgive my ignorance, but I don't understand this explanation - where exactly do I find the re-execute button then?

The previous re-execute should was preserved for the non-manual promotion (as you pointed out).

Are you saying that manual promotions are not allowed to be re-executed? If so, why not? Put another way, Damien Nozay pointed out an if condition for manual promotions - why does that condition exist?

I have the same question as above, what does "The manually approved "re-execute" button just moved into the Badge" mean. I can't find this ability to re-execute and it's a real problem for our users.

+1 with sdr984

What does it even mean by "Badge"??

I like to add i also have problems with the Rexecute Button that is not shown. I have a job with 3 different promotion tasks. Two Of them show the reexecute button. One of them isn't. I can not find any difference in the configuration between the 3 that justifies this difference.

I am also surprised to see that there is no 're-execute promotion' button. We use the promotion function to deploy software to infrastructure. The 're-execute promotion' on an old build would be a great way to roll back software.

The only work around I found for this issue is to make sure you do an 'Approve' promotion first instead of 'Force Promotion'. If you do a force promotion first, there is no re-execute.

I don't seem to have an 'Approve' button, only a 'Force Promotion' button. I'm doing manual approvals only, and the only thing the promotion does is trigger a downstream parameterized deploy job. It is strange, though, because the help text indicates there should be an 'Approve' button in the UI. I'm using plugin version 2.17 and Jenkins version 1.568

bug project folder

seems I'm not allowed to upload files here....
I lost also the commet I wrote. I rewrite it here:

Here my job. Note that I'm using AD authentication and there is a user with a numerical ID that is authorized to approve the promotion.
This user is also administrator of the whole jenkins, so it can "force the promotions"

the only selected criteria is:

[X] Only when manually approved

BUT attention: if I promote regularly with the "approve" button all is ok. The problem came only when I use the "force promotion" button.

I sent you by mail a tgz of a job that show the problem.
Bye Marvi

I was able to reproduce by using "Force Promotion" instead of "Promote". I am wondering if that is everybody case?
The problem with "Force Promotion" is that it will ONLY work for promotion with NO parameters.
In my organization, we NEVER use force promotion.

I've attached a job with this issue.

Yes, I only have this issue when force promotion is used. If a promotion is forced and then fails, there is no way to redo the promotion.

A problem which was leading me to use force promotion: if a promotion has some improperly set criteria then it is impossible to do a regular promotion. For example, if "When the following upstream promotions are promoted" is checked but the box for it is not filled out, clicking Approve will give the "Re-execute Promotion" button, but the promotion will never execute. It does not give any reason why, but it will say upstream promotions under unmet qualifications, but the upstream promotions is blank so that doesn't really indicate anything. If you click the "Re-execute Promotion" button again, you get a 404 error. The only option at that point is to force the promotion, and if it fails you are then completely unable to execute the promotion. I did not check if this also occurs for other invalid settings than the "upstream promotions are promoted" setting.

Thanks Marvi and Erik, the project files were very helpful.
Anybody want to try my latest build with the fix? See Attachments

Fix promoted-builds-2.18-20140807.061532-2.hpi worked for me.
thanks.

https://github.com/jenkinsci/promoted-builds-plugin/pull/45

Fixed/Workaround in version 2.20.

https://github.com/jenkinsci/promoted-builds-plugin/commit/8e0e17b1e21624cb3db68f23b868fb15d280aae3

The fix was to remove the button display condition which was `isManuallyApproved()`.
Promotions that are "Forced" are not the same as "manually approved".
It is now displayed unconditionally.

There are many use cases for re-executing the promotion, two of them are:
1. it didn't work the first time, duh!
2. side-effects that you want to re-execute.

The "Force promotion" workflow may very well be broken.
You may be able to get more data using/adapting the following groovy script:

import hudson.plugins.promoted_builds.*;

jobs = hudson.model.Hudson.instance.getAllItems(FreeStyleProject)
job = jobs[0]

build = job.lastSuccessfulBuild

println build.actions

build.getAction(PromotedBuildAction.class).promotions.each { 
  p -> 
  println "promotion:" + p.name + ", manual:" + p.manuallyApproved + ", success:" + p.promotionSuccessful
  println p.badges
}