BTW we have a CB support contract.

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.

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?

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).

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

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.

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.

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

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

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

hmm running into this right now. What version was this fixed in?

amuniz Could you please release the plugins version that include this fix?

The last version, 1.3.1 is 2 years old.

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?