|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I have written a ruby tool for analyzing and fixed build history problems...
https://github.com/docwhat/jenkins-job-checker
If you run jobber.rb with --solve it'll try to fix problems, otherwise it just prints out how it would have solved the problem (in addition of a description of the problem(s)).
The cases that look the most interesting to me are builds that are :STOLEN (e.g. two date-directory's build.xml files have the same <number>) and :NEXT (e.g. the nextBuildNumber is a number that has already been used).
I suspect these are related to the builds missing. Because the builds that disappear are after the duplicate builds. This includes jobs the "Some projects have builds whose timestamps are inconsistent. These will confuse Jenkins when it tries to look up build records." thingy doesn't catch!
I also notice the "Some projects have builds whose timestamps are inconsistent." message doesn't re-check when the job and build history is re-read from disk or when jobs are pruned due to being old.
If this duplication isn't part of the problem, I apologize for clouding the issue. If it is part of the problem, then JENKINS-11853 is probably related to this bug too.
A nice feature for troubleshooting this would be an option to only load a specific job from disk instead of everything. Assuming that's possible...