For me fix, using v1.494 was simply copy excisting faulty job to new one.

Probably the renaming of job / project causes this. The ridicilous side effect of this is that there are no validation check for current build number and just created / [successfuly] built and archived artifacts. If there would be simple excistance check that would valida that last build actually created artifacts and they ARE ACCESSIBLE to user, In my build system that would be pretty minor issue. Currently hitting on this is pretty pain-in-ass catogrizable one...

Always wonder why to implement new features instead of simply avoid / fix blockers lurking everywhere in jenkins core :/

As a matter of fact I renamed these builds some time ago as well... This might be one part of the issue.

I have had this issue occur without ever renaming any jobs, so I'm afraid the bug is a little more complicated. When it does happen, it is often for more than one job. Without doing anything, the problem can disappear the next time I open the web interface. Or sometimes it is more persistent and doesn't go away until I reload configuration from disk. I have versions 1.497 and 1.500 running on two separate WS2008R2 servers and it has happend on both. Fortunately, it hasn't happened very often lately...

Ok. First of all - devs got to understand the point this nonsense started. On my second machine, using v1.454, this has never happened. Others ... ? Seems like Jenkins infrastructure does not have any way to do some regression tests ... like, for example, WineHQ guys got ...

Hello,
We had a similar problem with v 1.483. It happened on several jobs which were never renamed. Reloading the configuration restored the situation for most jobs. For few, some builds were missing in the history. After analysis, the missing builds were also lacking the build.xml in the "build/<TimeStamp>" folder.

for me it happens since lazy loading of build records was introduced, so version 1.485.
I haven't verified that reverting back to 84 fixes it.

the issue of jenkinsuserfrance in 483 is probably something else, because the build/ folder is perfectly alright it just does not load whats in there.

Right, it is entirely possible there are two or more unrelated bugs lumped together here: at least, one present already in older versions of unknown cause; and one triggered by job renaming in 1.485+.

Hi all,

I have found a way to reproduce in our environment. Not sure if this will be the same for all of you, but maybe it is a start for debugging. I noticed recently that while un-shelving a job (plugin we use quite frequently) a job that was running displayed a strange 404 error in the console. See below

15:27:09 [WARNINGS] Parsing warnings in console log...
15:27:09 Archiving artifacts
Status Code: 404
Exception:
Stacktrace:
(none)

I then went back job page and refreshed and the build had disappeared. A reload from disk brought it back as usual. I have recreated a couple of times now, so not sure if the Shelve plugin is the culprit or some other underlying piece that interacts with plugins.

Also, I don't always get the 404 in the console, sometimes after starting a un-shelving job, the link for the build console goes right tot a generic 404 error page.

Jenkins 1.480.1
Windows Server 2008 R2 (Master and Slave)

Can anyone else recreate this way?

Not sure this is caused by renaming as we do not rename jobs but had this problem very frequently (because of the number of jobs). Reverting back to version before 1.485 made this problem disappear. This is, imho, clear sign that lazy loading could be culprit.

BTW, we don't have shelve plug-in.

Is there any code coverage taken, that is executed WITH and WITHOUT this lazy loading implementation?

https://github.com/jenkinsci/jenkins/pull/688

Maybe it is worth to design some test-suite / test-set to debug such bugs as these issues made my department to think about moving to other CI solution... In heavy 5 - 10 minute build re-queing this is simply not accaptable

Another one ...

@jglick can you confirm whether or not the fix will make it for 1.501?

@johno the fix has not been accepted yet; pending review. If I do not get a chance to look at it myself this week I will bring it to Kohsuke’s attention ASAP.

Sorry for the delay to update this....
I observed the same kind of issue today in our Jenkins setup. We are using 1.458 version.

Our setup have more than 60 jobs and master is Linux.

I uploaded one change, but build triggered by that event was not displayed in the BuildHistory.
After restarting Jenkins, the build is displayed in Jenkins.

We are using GerritTrigger plugins to trigger build.
In the job, the builds are running in slave.
The Job was triggering properly. No rename happened for the job.

I have encountered this same problem.
Jenkins 1.499
Server CentOS 6.2
Restarting Jenkins shows missing builds.

Code changed in jenkins
User: Julian Schmidt
Path:
test/src/test/java/hudson/model/AbstractProjectTest.java
http://jenkins-ci.org/commit/jenkins/dbd6b530e7c1a7008dceff4ecc816eda9fc24ef1
Log:
JENKINS-15156 Add regression test

Code changed in jenkins
User: Julian Schmidt
Path:
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
http://jenkins-ci.org/commit/jenkins/2feb19ef3406838806749d65201b84781207555f
Log:
[FIXED JENKINS-15156] Initialize AbstractLazyLoadRunMap.dir for newly created jobs

Code changed in jenkins
User: Johno Crawford
Path:
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
test/src/test/java/hudson/model/AbstractProjectTest.java
http://jenkins-ci.org/commit/jenkins/8f62901ee5265079598bc14dc9ade5196b5f066a
Log:
Merge remote-tracking branch 'tsartarzan/JENKINS-15156' into JENKINS-15156

Code changed in jenkins
User: Johno Crawford
Path:
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
test/src/test/java/hudson/model/AbstractProjectTest.java
http://jenkins-ci.org/commit/jenkins/fe95fc53f891542e63e24a64c0b7add60ac91c64
Log:
JENKINS-15156 Refactored fix.

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
test/src/test/java/hudson/model/AbstractProjectTest.java
http://jenkins-ci.org/commit/jenkins/25f4c60f967da16607f4653a291c37c9383a301d
Log:
Merge pull request #696 from johnou/JENKINS-15156

[FIXED JENKINS-15156] Initialize AbstractLazyLoadRunMap.dir for newly created jobs.

Compare: https://github.com/jenkinsci/jenkins/compare/e43e5f338e74...25f4c60f967d

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/fad1df3272d2ad6c01bd8eab2582de38c61d9472
Log:
JENKINS-15156 Noting.

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Integrated in jenkins_main_trunk #2248
JENKINS-15156 Add regression test (Revision dbd6b530e7c1a7008dceff4ecc816eda9fc24ef1)
[FIXED JENKINS-15156] Initialize AbstractLazyLoadRunMap.dir for newly created jobs (Revision 2feb19ef3406838806749d65201b84781207555f)
JENKINS-15156 Refactored fix. (Revision fe95fc53f891542e63e24a64c0b7add60ac91c64)
JENKINS-15156 Noting. (Revision fad1df3272d2ad6c01bd8eab2582de38c61d9472)

Result = UNSTABLE
ju.schmidt : dbd6b530e7c1a7008dceff4ecc816eda9fc24ef1
Files :

• test/src/test/java/hudson/model/AbstractProjectTest.java

ju.schmidt : 2feb19ef3406838806749d65201b84781207555f
Files :

• core/src/main/java/hudson/model/AbstractProject.java
• core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java

johno : fe95fc53f891542e63e24a64c0b7add60ac91c64
Files :

• core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
• test/src/test/java/hudson/model/AbstractProjectTest.java
• core/src/main/java/hudson/model/AbstractProject.java
• test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java

Jesse Glick : fad1df3272d2ad6c01bd8eab2582de38c61d9472
Files :

• changelog.html

Code changed in jenkins
User: Jesse Glick
Path:
test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
http://jenkins-ci.org/commit/jenkins/74e6409a06531144316f2e36bdc0b069de52b94d
Log:
JENKINS-15156 Class loading errors can result from OOME if you are not careful.

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/model/AbstractProject.java
http://jenkins-ci.org/commit/jenkins/7ac15767bca327dae5a904dd66f717e5e6269be6
Log:
JENKINS-15156 Massive test failures with NPE.
Seems that the RunMap must be initialized before updateTransientActions, which uses it, is called.

Compare: https://github.com/jenkinsci/jenkins/compare/fad1df3272d2...7ac15767bca3

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Integrated in jenkins_main_trunk #2249
JENKINS-15156 Class loading errors can result from OOME if you are not careful. (Revision 74e6409a06531144316f2e36bdc0b069de52b94d)
JENKINS-15156 Massive test failures with NPE. (Revision 7ac15767bca327dae5a904dd66f717e5e6269be6)

Result = UNSTABLE
Jesse Glick : 74e6409a06531144316f2e36bdc0b069de52b94d
Files :

• test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java

Jesse Glick : 7ac15767bca327dae5a904dd66f717e5e6269be6
Files :

• core/src/main/java/hudson/model/AbstractProject.java

Jesse, is there any code made for this idea?

"there are no validation check for current build number and just created / [successfuly] built and archived artifacts. If there would be simple excistance check that would valida that last build actually created artifacts and they ARE ACCESSIBLE to user, In my build system that would be pretty minor issue. "

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/model/AbstractProject.java
http://jenkins-ci.org/commit/jenkins/37bf35b5dbb0ccdc34ad0c3643a0802c17e232dc
Log:
JENKINS-15156 AbstractProject.builds accessed by Maven & matrix module builds before onLoad or onCreatedFromScratch called.
Seem to need to keep the deprecated no-arg RunMap initializer though it is unclear to me how it could work.

Integrated in jenkins_main_trunk #2252
JENKINS-15156 AbstractProject.builds accessed by Maven & matrix module builds before onLoad or onCreatedFromScratch called. (Revision 37bf35b5dbb0ccdc34ad0c3643a0802c17e232dc)

Result = UNSTABLE
Jesse Glick : 37bf35b5dbb0ccdc34ad0c3643a0802c17e232dc
Files :

• core/src/main/java/hudson/model/AbstractProject.java

hmm. Is there any hope to get this fix-set STABLE?

Current build stability is STABLE, see https://ci.jenkins-ci.org/job/jenkins_main_trunk/ .

Linked another one that might be connected to this issue / side-effects...

Did the fix make it into 1.501? I upgraded one of our servers to 1.501 today and haven't noticed any problems so far, but the Build History timeline graphical display isn't showing all of the builds.

@richardm_tx: 1.502 I think.

Hard to tell if this fix made it in to 1.502 since they forgot to update the changelog. :/
The Build History timeline graphical display still isn't showing all of the builds, so maybe that'll have to be written up as a separate bug.

The fixes made it into the 1.502 release. Its listed in the changelog (lines 67 & 68)

https://github.com/jenkinsci/jenkins/blob/5bca85d99253a85ae6085fc38ac592d97d8e98e6/changelog.html

Could anyone please confirm that issue is fixed?

It wouold be better to confirm linked issues first. Then this one. It would be good to keep histroical / hearichal view on this issue as I have feeling this is not last time devs will run in such circular issues ...

Nickolay: I upgraded one of our servers (with version 1.502) and have not seen the issue come back yet. So I feel comfortable upgrading our other servers with this build. Also tested copying jobs as noted in JENKINS-16735 and my history on the source job did not disappear. No guarantees, but so far it looks good.

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/model/AbstractProject.java
core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
http://jenkins-ci.org/commit/jenkins/09c7cf6ad7cfb4d88d6d8936f29b13f3ca187875
Log:
JENKINS-15156 Found a problem with uninitialized run maps in new Maven modules.
Not observed in actual usage, but reproducible (for me at least, though apparently not ci.jenkins-ci.org) in a test:
java.lang.AssertionError: null
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:628)
at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:581)
at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:243)
at java.util.AbstractMap$2$1.<init>(AbstractMap.java:378)
at java.util.AbstractMap$2.iterator(AbstractMap.java:377)
at hudson.util.RunList.iterator(RunList.java:103)
at hudson.util.RunList.size(RunList.java:114)
at hudson.maven.MavenProjectTest.testDeleteSetBuildDeletesModuleBuilds(MavenProjectTest.java:159)

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Integrated in jenkins_main_trunk #2290
JENKINS-15156 Found a problem with uninitialized run maps in new Maven modules. (Revision 09c7cf6ad7cfb4d88d6d8936f29b13f3ca187875)

Result = SUCCESS
Jesse Glick : 09c7cf6ad7cfb4d88d6d8936f29b13f3ca187875
Files :

• maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
• core/src/main/java/hudson/model/AbstractProject.java
• core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java

Sorry, but failed builds still disappear on Jenkins v1.502...

Still disappearing at 1.502 (at least for failed builds)

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/matrix/MatrixProject.java
http://jenkins-ci.org/commit/jenkins/42ee6113b7beff8dccba48593cefe0ad23636051
Log:
JENKINS-15156 Missing call to onCreatedFromScratch caused failures in MatrixProjectTest (when run from Surefire at least).

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Integrated in jenkins_main_trunk #2311
JENKINS-15156 Missing call to onCreatedFromScratch caused failures in MatrixProjectTest (when run from Surefire at least). (Revision 42ee6113b7beff8dccba48593cefe0ad23636051)

Result = SUCCESS
Jesse Glick : 42ee6113b7beff8dccba48593cefe0ad23636051
Files :

• core/src/main/java/hudson/matrix/MatrixProject.java

With 1.502 problem is still there but it has changed a bit. Now i can see the history for project on left side but when i select particular build and try to narrow down to particular configuration of multi-configuration project it tells that configuration was never built. From the main page of multi-configuration project when i click on configurations i cannot see the history of builds. Reloading configuration from disk is still a workaround that can be used but still this blocks chained builds that try to copy artifacts from one build to another.

A similar issue is affecting me in version 1.484. I can see all of the previous builds for a job on the left side of the page, but clicking on one of them shows no configurations available (there should be a "default" configuration). Because of this, I cannot view the console output of old builds. This affects all of my builds except for the most recently built job.

I know the console output exists though because I can see it in $JENKINS_HOME/jobs/<job>/configurations/builds/<build date>/log

Reloading configuration from disk actually made it worse, by losing the link to the most recently built job's build history.

@nickolay_martinov: I recently found an issue in matrix projects that was caught by tests under some conditions, and fixed it in trunk (1.505 I think). I cannot say that this will fix your issue, or even that the fix has any effect in real usage; just a hint.

builds.dir of new created MatrixConfiguration is always set to null.
This causes Jenkins fail to load builds of configurations from the disk (AbstractLazyLoadRunMap.load).

MatrixConfiguration.builds (that is AbstractProject.builds) is initialized with new RunMap(), which sets builds.dir to null.
When the configuration is load from the disk, builds is correctly initialized and dir is set.

When new MatrixConfiguration is created (including the case a new axis is added), MatrixConfiguration.onLoad nor MatrixConfiguration.onCreatedFromScratch seem not called. It may concerned with this problem.

I think this can be considered fixed (for 1.505+ users), at least for core; plugins defining new project types with nested items (I am thinking of Ivy) may need to be patched too, TBD. Anyway if problems remain in newer builds it may be better to file a new bug linked to JENKINS-8754.

This issue number doesn't show up in the changelog for version 1.505 or 1.506. Is it really fixed?

Jenkins changelogs are not particularly trustworthy. The last commit did not add a changelog entry since it was done just to fix a test failure; I never reproduced any user-visible problem. I will add one now.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/c596ed517c3f67bff172cfa0d3ac62e01d35dd54
Log:
JENKINS-15156 Noting.

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Integrated in jenkins_main_trunk #2362
JENKINS-15156 Noting. (Revision c596ed517c3f67bff172cfa0d3ac62e01d35dd54)

Result = SUCCESS
Jesse Glick : c596ed517c3f67bff172cfa0d3ac62e01d35dd54
Files :

• changelog.html

I have this problem in 1.500 and is still there after upgrading to 1.505.

I have several jobs and some or all of them loose all their build history. It seems a bit sporadic and I have not seen a pattern. I have renamed most of my jobs but history with the current name just disappeared on me now.

I confirm regression! please re-open this. Is getting annoying.

Better to not reopen long-running issues like this, which just results in an unreadable mess, and results in confusion about whether fixes were really applied. In this case they were, so it is likely that your problem has a different origin. Please file a fresh issue blocking JENKINS-8754 and clearly stating your Jenkins version, platform, list of plugins, exact observed behavior, and any other information you have which might help developers reproduce the problem or even guess at its cause.

Filed https://issues.jenkins-ci.org/browse/JENKINS-17265, as the issue still persists on 1.506.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/plugins/promoted_builds/JobPropertyImpl.java
http://jenkins-ci.org/commit/promoted-builds-plugin/add555747e7d94e27e019db47523e74c0a94c1b0
Log:
JENKINS-15156 PromotionProcessTest failed with parent set to 1.507 because in lazy-loading versions of Jenkins the build list for a project must be explicitly created.

I have build histories disappearing on new jobs created since I updated to LTS release 1.509.1.

Reloading configuration from disk seems to resolve the issue.

Did the fix for this make it into 1.509.1?

Kevin,

By the http://jenkins-ci.org/changelog this was fixed in 1.505 (2013/03/10).

But this is being fixed and reopened for a couple of times now...!

Please re-open the issue, again

@pedroreis rather than reopening an issue with a known fix, which makes it very hard to track what version of Jenkins has which fix, please file separate bug reports (linked to JENKINS-8754) with details to reproduce the problem. Without a known way to reproduce, or at least some error messages in the log etc., it is impossible to diagnose anything.

Hi, it is still reproducible for me in Jenkins ver. 1.511. It happens for jobs that were copied from existing ones. I think JENKINS-8754 is not related.
reopening.

Jessie, it still happens, see my separate comment in thread. Do you ensist than new issue has to filed here?

@vladichko yes, see previous comments about filing fresh issues with steps to reproduce or other analysis. There was a documented bug here, which was fixed; there may be other bugs with superficially similar symptoms, but it does no good to dump them all in the same issue.

BTW one fix here was in Promoted Builds 2.10, not core.

can we get it to core?

@vladichko I meant that a problem was observed in a plugin due to changes in core, and the fix for this problem was made in that plugin.

Fix assignee

Hello,

I'm using Jenkins v 1.517 and I'm experiencing a very similar (if not the same) problem. All builds are visible on the master machine but older builds, from time to time, simply disappears from the list of builds on the slave machine. Is this problem fixed in actual or upcoming version?

Please see the attached screenshot (disappeared history of builds on slave machine).

@odklizec your problem looks unrelated: matrix configuration builds getting deleted from disk (not just sporadically failing to appear in the web UI). As above, if you can figure out under which conditions this happens, file a separate bug report.

@Jesse thanks for the reply. OK, I will keep an eye on this issue.

I'm currently facing this issue with version 1.526. A workaround is to move to "manage jenkins" and click the "Reload Configuration from Disk" link.

Also experiencing this issue since at least 1.505. Build history disappears for certain builds, seems to be most prevalent in cloned builds. "Reload configuration" does not work for me. Currently running 1.526 and issue remains. Cloned build plans are susceptible to this. "Fix" seems to be to avoid use of clone to create a new build plan, and to create a new build from scratch each time. This is not good, since our builds contain many common steps, and manual re-entry of information for a new build can create new errors in the plan. Interestingly, if a new build plan is created with the same information as the original cloned plan and the new build plan is given the same name as the original "lossy" cloned build plan, the all-new build plan inherits the history disappearance problem as well! There may be a problem with build plan attribute inheritance when a cloned build plan is created.

I really don't know why this issue is marked as resolved?!

when I click on build history on the left Jenkins menu bar, there are not displayed any built jobs?

@ntshako: there are numerous underlying problems that could produce this general visible symptom, and these would get tracked as separate bug reports. I cannot guess what the problem is in your case; we are incrementally fixing issues and adding diagnostics, but in general a Jenkins developer needs to analyze your system to diagnose.

Why not just keep this as a parent issue, with specific conditions as child issues?

Setting an issue to "Resolved" when it clearly is not, is unhelpful for everyone, no matter what the rational. They're called "issues" because they track issues.

I'm more then a little frusterated running into many, many absolutely catastrophic show stopping bugs in every recent Jenkins release, only to find them already reported in Jira and marked "Resolved", when nothing could be farther from the truth.

If you Won't Fix a bug, please at least have the curtsey to your users of flagging the bug Won't Fix rather then lie and call it Resolved.

why not just create them and link them to this issue as a parent?

Please go ahead. It is better for the user encountering the issue to actually file the report though.

I'm wondering how we (users who don't know internals of Jenkins) are supposed to know if our "build history disappears" problem (symptom) is a result of #15156, #17265 or of any other issue with the similar title and description… This applies to other "symptoms" as well.

@binary: if you do not know any internals of Jenkins, you generally cannot know this. All you can know for sure is that if you are running a build newer than the one with a particular fix, such as JENKINS-17125 (1.509.3/1.519), then your symptoms are not a result of the known bug (error-prone FingerprintAction serial form in build.xml in that case).

If you know how to reproduce the problem from scratch, then it does not matter what you know about Jenkins internals; just file a bug report with those steps and let someone else figure out what is going on inside and what relation this might have to previously filed reports or recent changes. Otherwise, filing an issue report is of limited value, which is why paid support exists: there are many more users with unsolved problems than there are volunteers sifting through reports and trying to guess what happened and collate all the data. Sometimes it is possible to immediately diagnose a mistake in code based on seeing the symptom (this is often true of exceptions with stack traces), but sometimes diagnosis without reproducibility would require detailed investigation (as with missing builds).

I have the same problem on 1.523, reloading the configuration from disk makes the missing builds reappear... is there an easy way to check against the remaining open issues to know which one in particular is affecting us ? the job is a cloned job but I don't have specific steps to reproduce the problem.

I have the same issue on 1.526 on Win2k12. Builds disappear from several jobs almost hourly. Reloading the configuration from disk usually brings some of them back, but not all. It's nearly becoming a blocking issue, as jobs are 'losing' their entire build history multiple times a day.

For all the recent posters, please note that the issue is considered as resolved by assignee. He insists on opening a new one if the issue is still relevant.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/maven/MavenModuleSetBuild.java
http://jenkins-ci.org/commit/maven-plugin/dc2215b85d3c1a2e1a4f3ba7b542c2bbc6d41776
Log:
JENKINS-15156 Found a problem with uninitialized run maps in new Maven modules.
Not observed in actual usage, but reproducible (for me at least, though apparently not ci.jenkins-ci.org) in a test:
java.lang.AssertionError: null
at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:628)
at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:581)
at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:243)
at java.util.AbstractMap$2$1.<init>(AbstractMap.java:378)
at java.util.AbstractMap$2.iterator(AbstractMap.java:377)
at hudson.util.RunList.iterator(RunList.java:103)
at hudson.util.RunList.size(RunList.java:114)
at hudson.maven.MavenProjectTest.testDeleteSetBuildDeletesModuleBuilds(MavenProjectTest.java:159)
Originally-Committed-As: 09c7cf6ad7cfb4d88d6d8936f29b13f3ca187875

Great news, Jesse! Looking forward for next version!

Jesse, whas is released? in what version?
I still observe it in 1.541

I still see it in 1.541
builds just dissapear ~once a week. Reload configuration helps.

@vladichko then you are seeing some other bug with a similar symptom. If you know how to reproduce it, then it can be fixed. Otherwise, maybe, maybe not.

Code changed in jenkins
User: Jesse Glick
Path:
test/src/test/groovy/hudson/model/AbstractProjectTest.groovy
http://jenkins-ci.org/commit/jenkins/85e9e126773c0bb20a8529a2e6591dde17d7e209
Log:
JENKINS-10615 AbstractProjectTest.testWorkspaceLock frequently fails on jenkins.ci due to InterruptedException in HudsonTestCase.setUp.
Possibly because it is sorted after JENKINS-15156 testGetBuildAfterGC and the test suite times out.

Is this Issue Fixed..As We are having the same issue on Jenkins ver. 1.509.4 LTS..Is there a fix for the issue??

@arvindramalingam you mean you are experiencing a different bug with a similar symptom. Without knowing how to reproduce from scratch we cannot help. See comments above.

Hi Jesse,

Thanks for the quick response.We have renamed the jobs and pointed it to a different release and the Build history keeps disappearing everyday.If there is a fix for the issue can you please send it to me so that I will build the war file with the change.

I see the builds on the server but not on the UI...The trend on the UI also does not show the history

Then you might be seeing JENKINS-18678.

Thanks Jesse..Ill follow up JENKINS-18678.

I'm having something similar; a build disappears at some point after completion...some times even during the build.

This is Jenkins 1.554.1 on Java:
java version "1.6.0_30"
OpenJDK Runtime Environment (IcedTea6 1.13.3) (rhel-5.1.13.3.el5_10-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

It impacts both jobs that we use the Job DSL for as well as for jobs are normal manually edited.

We can "work around" the problem (without having to reload the whole config from disk, which has in the past caused problems with plugins like GerritTrigger) by doing one of the following:

1. Click 'configure' then immediately click 'save'. The missing builds sometimes reappear. (In previous versions of Jenkins, but it isn't working in 1.554.1 apparently).
2. If we're lucky, we can click 'trends' and the build will be there. We click on it and the missing builds magically reappear.

I've noticed that some jobs behave badly (e.g. fail with weird messages from Jenkins) after updating plugins until I go in and click 'configure' and then 'save' immediately (without changing anything). I've looked at the config.xml and it does change, sometimes new elements get added, or plugin versions are bumped. I'm unsure if the config.xml changing is part of the problem/work-around or if saving just causes Jenkins to rescan things.

It's not reproducible, but if someone can suggest things they'd like us to record/look-at when it happens again I'd be happy to do it. I'm not a Java debugging expert, but I can pull some in.

EDITED: Fixed my using 'job' when I meant 'build'.

docwhat:

job disappears at some point after completion

The jobs sometimes reappear

This issue is about builds disappearing. Are you confusing terminology, or are experiencing completely unrelated symptoms?

Ugh.

I'm sorry danielbeck, I meant 'build'. I'll re-edit that comment to be correct.

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