[JIRA] (JENKINS-38641) Milestone step fails to pass due to deleted/future builds having passed

5 views
Skip to first unread message

davidkarlsen@java.net (JIRA)

unread,
Sep 30, 2016, 6:37:01 PM9/30/16
to jenkinsc...@googlegroups.com
davidkarlsen created an issue
 
Jenkins / Bug JENKINS-38641
Milestone step fails to pass due to deleted/future builds having passed
Issue Type: Bug Bug
Assignee: Antonio Muñiz
Components: pipeline-milestone-step-plugin
Created: 2016/Sep/30 10:36 PM
Environment: 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.
Priority: Minor Minor
Reporter: davidkarlsen
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

davidkarlsen@java.net (JIRA)

unread,
Sep 30, 2016, 6:37:02 PM9/30/16
to jenkinsc...@googlegroups.com
davidkarlsen updated an issue
Change By: davidkarlsen
Environment: 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.

davidkarlsen@java.net (JIRA)

unread,
Sep 30, 2016, 6:37:02 PM9/30/16
to jenkinsc...@googlegroups.com
davidkarlsen updated an issue
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.
Add Comment Add Comment
 

davidkarlsen@java.net (JIRA)

unread,
Sep 30, 2016, 6:38:01 PM9/30/16
to jenkinsc...@googlegroups.com
davidkarlsen updated an issue
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 currently available build - not the highest number in history.

davidkarlsen@java.net (JIRA)

unread,
Oct 1, 2016, 8:15:07 AM10/1/16
to jenkinsc...@googlegroups.com

amuniz@cloudbees.com (JIRA)

unread,
Oct 3, 2016, 4:18:01 AM10/3/16
to jenkinsc...@googlegroups.com

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 be triggered (will be #7) so it will pass the milestone.

Am I missing something? Can you provide more info about your use case then?

amuniz@cloudbees.com (JIRA)

unread,
Oct 3, 2016, 4:20:01 AM10/3/16
to jenkinsc...@googlegroups.com
Antonio Muñiz edited a comment on Bug JENKINS-38641

davidkarlsen@java.net (JIRA)

unread,
Oct 3, 2016, 11:52:01 AM10/3/16
to jenkinsc...@googlegroups.com

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.

amuniz@cloudbees.com (JIRA)

unread,
Oct 3, 2016, 2:01:01 PM10/3/16
to jenkinsc...@googlegroups.com

So what you want to get fixed is JENKINS-36029, not this.

amuniz@cloudbees.com (JIRA)

unread,
Oct 3, 2016, 2:01:03 PM10/3/16
to jenkinsc...@googlegroups.com
Antonio Muñiz closed an issue as Not A Defect
 
Change By: Antonio Muñiz
Status: Open Closed
Resolution: Not A Defect

amuniz@cloudbees.com (JIRA)

unread,
Oct 3, 2016, 2:10:01 PM10/3/16
to jenkinsc...@googlegroups.com
Antonio Muñiz edited a comment on Bug JENKINS-38641
So what you want to get fixed is JENKINS-36029, not this. I just posted a possible workaround - until it is fixed.

davidkarlsen@java.net (JIRA)

unread,
Oct 4, 2016, 7:43:01 AM10/4/16
to jenkinsc...@googlegroups.com

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?

amuniz@cloudbees.com (JIRA)

unread,
Oct 7, 2016, 9:31:01 AM10/7/16
to jenkinsc...@googlegroups.com

davidkarlsen if you are using a "Bitbucket Team/Project", then make sure you have installed branch-api plugin at 1.8 or above, so Orphaned Item Strategy is propagated to every repository discovered on folder computation. The workaround should work (and 1 day should be enough, unless your Bitbucket instance is down more than 24 hours).

simon.norra@codecentric.de (JIRA)

unread,
Nov 11, 2016, 5:19:01 AM11/11/16
to jenkinsc...@googlegroups.com

I did face a very similar issue.

In our project we create pipeline jobs per branch with Job DSL for a lot of microservice projects. We are using the milestone plugin as well and were very happy with this. Accidentally a change to our Job DSL script caused the seed job to delete all pipeline jobs. After fixing the issue the jobs were created again, causing all jobs to fail, because they were going to start at build number 1.

The output looks like this

[Pipeline] milestone
Trying to pass milestone 1
Canceled since build #6 already got here
[Pipeline] End of Pipeline

To reproduce this:

  • Create a job named "test-pipeline"
  • add: 
    stage "BUILD"

echo "I do something"

stage "RELEASE"

milestone 1
input message: 'Do you want to release me?', ok: 'Go, release, go!'
milestone 2

echo "Yes, I am released!"
  • Just try the job a few times and accept the input prompt
  • The milestone plugin behaves as expected
  • Now delete the job
  • Now create the job again, with exactly the same name and pipeline DSL script
  • Start the job
  • Now the job fails because the build counter is not reset and the job "thinks" the build is older than a previous one of the first, deleted job

This currently makes the usage of the milestone plugin useless for us. Or is there anything we can do about it?

Thank you

mdouglass@kixeye.com (JIRA)

unread,
Nov 22, 2016, 2:31:01 AM11/22/16
to jenkinsc...@googlegroups.com

I too just ran into this bug. We deleted a job to clear out old history, recreated it and all of our builds now fail because of milestones on an old version.

I highly disagree with the milestone data surviving deletion of the entire job. Given the current architecture, if I ever delete a job that uses milestones than that job name is forever unusable on that server. That seems highly undesirable to me.

mdouglass@kixeye.com (JIRA)

unread,
Nov 22, 2016, 2:31:02 AM11/22/16
to jenkinsc...@googlegroups.com
Matthew Douglass reopened an issue
 
Change By: Matthew Douglass
Resolution: Not A Defect
Status: Closed Reopened

mdouglass@kixeye.com (JIRA)

unread,
Nov 22, 2016, 2:31:02 AM11/22/16
to jenkinsc...@googlegroups.com
Matthew Douglass updated an issue
Change By: Matthew Douglass
Priority: Minor Blocker

amuniz@cloudbees.com (JIRA)

unread,
Nov 24, 2016, 6:33:04 AM11/24/16
to jenkinsc...@googlegroups.com
Antonio Muñiz commented on Bug JENKINS-38641
 
Re: Milestone step fails to pass due to deleted/future builds having passed

Ok. If this is happening when a job is deleted and recreated for some reason (intead of deleting builds), then looks like a valid bug.

A JobListener has to be added to monitor job deletions so the internal status tracking file can be updated accordingly.

amuniz@cloudbees.com (JIRA)

unread,
Nov 24, 2016, 6:39:02 AM11/24/16
to jenkinsc...@googlegroups.com
Antonio Muñiz updated an issue
 
Change By: Antonio Muñiz
Priority: Blocker Major

amuniz@cloudbees.com (JIRA)

unread,
Nov 24, 2016, 6:44:01 AM11/24/16
to jenkinsc...@googlegroups.com
 
Re: Milestone step fails to pass due to deleted/future builds having passed

Downgrading to major as remove/readd a job with the same name is not a frequent task in a production environment.

BTW the workaround (ugly but a workaround) is to edit the file JENKINS_HOME/org.jenkinsci.plugins.pipeline.milestone.MilestoneStep.xml and remove the entry element about the removed job (the job name is in //entry/string). It will be regenerated automatically after the first run of the new job.

pwolf@cloudbees.com (JIRA)

unread,
Dec 1, 2016, 12:36:02 PM12/1/16
to jenkinsc...@googlegroups.com
Patrick Wolf assigned an issue to CloudBees Inc.
 
Change By: Patrick Wolf
Assignee: Antonio Muñiz CloudBees Inc.

amuniz@cloudbees.com (JIRA)

unread,
Dec 5, 2016, 7:32:02 AM12/5/16
to jenkinsc...@googlegroups.com
Change By: Antonio Muñiz
Status: Reopened Open

amuniz@cloudbees.com (JIRA)

unread,
Dec 5, 2016, 7:32:02 AM12/5/16
to jenkinsc...@googlegroups.com
Antonio Muñiz assigned an issue to Antonio Muñiz
Change By: Antonio Muñiz
Assignee: CloudBees Inc. Antonio Muñiz

amuniz@cloudbees.com (JIRA)

unread,
Dec 5, 2016, 7:32:02 AM12/5/16
to jenkinsc...@googlegroups.com
Antonio Muñiz started work on Bug JENKINS-38641
 
Change By: Antonio Muñiz
Status: Open In Progress

scm_issue_link@java.net (JIRA)

unread,
Dec 28, 2016, 7:08:04 AM12/28/16
to jenkinsc...@googlegroups.com
SCM/JIRA link daemon commented on Bug JENKINS-38641
 
Re: Milestone step fails to pass due to deleted/future builds having passed

Code changed in jenkins
User: Antonio Muñiz
Path:
.gitignore
src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java
src/test/java/org/jenkinsci/plugins/pipeline/milestone/CleaupJobsTest.java
http://jenkins-ci.org/commit/pipeline-milestone-step-plugin/b9fedb94930868b19987f3acb42d3e1030f11bb3
Log:
JENKINS-38641 Clean up tracked jobs on deleted

scm_issue_link@java.net (JIRA)

unread,
Dec 28, 2016, 7:08:05 AM12/28/16
to jenkinsc...@googlegroups.com
SCM/JIRA link daemon resolved as Fixed
 
Change By: SCM/JIRA link daemon
Status: In Progress Resolved
Resolution: Fixed

scm_issue_link@java.net (JIRA)

unread,
Dec 28, 2016, 7:08:05 AM12/28/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Antonio Muniz
Path:
http://jenkins-ci.org/commit/pipeline-milestone-step-plugin/9826f7a8996a54c5fe6fbb7ee5414fe9dc2cd673
Log:
Merge branch 'master' into JENKINS-38641

scm_issue_link@java.net (JIRA)

unread,
Dec 28, 2016, 7:08:06 AM12/28/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Antonio Muniz
Path:

.gitignore
src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java
src/test/java/org/jenkinsci/plugins/pipeline/milestone/CleaupJobsTest.java
http://jenkins-ci.org/commit/pipeline-milestone-step-plugin/a0434815e3d37cfce9ced2ee97b957cf650017f4
Log:
Merge pull request #6 from amuniz/JENKINS-38641

[FIX JENKINS-38641] Clean up tracked jobs on deleted

Compare: https://github.com/jenkinsci/pipeline-milestone-step-plugin/compare/5077e3a1200b...a0434815e3d3

plaporte@nuglif.com (JIRA)

unread,
Apr 10, 2019, 3:53:01 PM4/10/19
to jenkinsc...@googlegroups.com

Antonio Muñiz Could you please release the plugins version that include this fix?

The last version, 1.3.1 is 2 years old.
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

gdan2000@gmail.com (JIRA)

unread,
Sep 26, 2019, 4:54:04 AM9/26/19
to jenkinsc...@googlegroups.com

We have the same problems. We had to delete many jobs and recreate them again.

And now we the same situation when builds are being aborted.

When are you going release fixed version?
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages