-
Bug
-
Resolution: Fixed
-
Major
-
None
23:35:58 Trying to pass milestone 0
23:35:58 Canceled since build #6 already got here
[Pipeline] }
But this is build #4 - which is the latest build! The newer builds have been deleted. So the milestone step plugin should consider what is the latest currently available build - not the highest number in history.
- links to
[JENKINS-38641] Milestone step fails to pass due to deleted/future builds having passed
| Environment |
Original:
23:35:58 Trying to pass milestone 0 23:35:58 Canceled since build #6 already got here [Pipeline] } But this is build #4 - which is the latest build! The newer builds have been deleted. So the milestone step plugin should consider what is the latest current ly available build - not the highest number in history. |
| Description |
New:
23:35:58 Trying to pass milestone 0 23:35:58 Canceled since build #6 already got here [Pipeline] } But this is build #4 - which is the latest build! The newer builds have been deleted. So the milestone step plugin should consider what is the latest current ly available build - not the highest number in history. |
| Description |
Original:
23:35:58 Trying to pass milestone 0 23:35:58 Canceled since build #6 already got here [Pipeline] } But this is build #4 - which is the latest build! The newer builds have been deleted. So the milestone step plugin should consider what is the latest current ly available build - not the highest number in history. |
New:
23:35:58 Trying to pass milestone 0 23:35:58 Canceled since build #6 already got here [Pipeline] } But this is build #4 - which is the latest build! The newer builds have been deleted. So the milestone step plugin should consider what is the latest currently available build - not the highest number in history. |
As far as I understand, milestone is behaving correctly, if build #6 already passed the milestone then #4 must be cancelled (it does not matter if #6 was deleted).
This step is designed to ensure newest code is delivered always over old states of the code base, so if your newest code state is the one being built in #4, then revert your code repository to that state so a new build is triggered (will be #7) so it will pass the milestone.
Am I missing something? Can you provide more info about your use case then?
The problem is that we have team-folders which rescan our repo - and it has a bug where if stash is down it will think the repo is gone, delete the jobs, recreate them (when the repo is back again) - so that the build get´s build #1 again.
Since the plugin relies on job-build-number, I think it should base it´s decision on the CURRENT available buildnumber - it would still be valid (e.g. deliver the latest available code). But it´s a bit silly (not smooth) that I have to provide 6 builds just to increase the build-number.
So what you want to get fixed is JENKINS-36029, not this. I just posted a possible workaround - until it is fixed.
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
Tried the workaround without that relly working out for me (it was set to 1 day, now changed to 7).
What happens if a branch is deleted (and hence a teamfolder-based job), then created again some days later? Will it remember that the milestone was for instance at #8 - so I need to do 8 new builds of my new branch again - just to pass the milestone?
BTW we have a CB support contract.