In my case, this might be related to JENKINS-13536, which causes loading of history to fail if the temp file store by the file upload plugin is removed.

My job keeps losing builds from the history all the time. An hour ago there where ten builds in the history, and now only the two most recent builds (out of a total of 175 builds) are shown.

All the build data is still available on disk, and the history will show correctly again for a while following a restart of the master.

12 hours later the history is back. This time without a master restart.

I have the same problem (1.485). Builds disappear from the history. Often only the most recent build is visible.

Attempting to access the URL of the missing builds manually (ie. append /51 to the job URL) produces a 404 Status Error (sorry, don't have exact text).

Confirmed that "Reload configuration from disk" fixes the problem - full build history is again visible, and the build URLs can be accessed manually too.

We have the same issue with 1.489. Restarting or reloading config from disk fixes this temporarily. Build history gets lost eventually after the next build. We have master/slave setup with 3 slaves executing jobs (all machines on Linux SLES)

Notice this in particular with newly created jobs, where all build history will vanish after a build or two.

I have seen this in 1.486 as well. I renamed a couple of jobs, and after that all history for those jobs disappeared.

same experience here. I renamed a couple of jobs and the build history disappeared. Restarting the server solves the issue

Those who are able to reproduce the bug, are you running a standalone Jenkins instance or do you have slaves configured?

I reproduced the issue when Job was renamed and was run on slave (was not checked on master)

johno: I have several build slaves configured in my setup.

This seems to happen only with master/slave (multiple nodes) setup.

We have a second Jenkins (both 1.489) with nearly the same configuration - the only difference is that this one has no slaves. There the problem does not occur.

I just started using Jenkins about a month ago, and it was happening with some frequency on stand-alone server (no master/slave setup). I haven't seen the problem in the last 2 weeks however. As per D C's comment, reloading from disk resolves the issue whenever I see it.

edit: just happened again a few minutes ago. may have been caused by renaming. renamed the job in question to make way for a better implementation of the same job, but I've done the same thing to a few others without seeing this.

This started happening for us after we upgraded to 1.494. Reloading configuration from file fixes temporarily. We have a Master/Slave setup.
Edit: This started happening, and continues to happen after every build, just after I renamed my project.

I have this problem after upgrading to 1.494. Master/Slave setup (all Linux box). Only the job create after upgrading has this problem. Those jobs created before upgrading work well.

(updated) I find all the builds exists in the build directory. The problem is that they are not shown in the build history.

changed priority to Critical.

(updated) I just upgrade to 1.495, then the history goes back!

This is happening with 1.494.
Reloading the configuration brings back the build logs.

I have this problem in 1.495 as well, master/slave mode

Reloading history isn't really a solution. Since CI is not for humans (why we need CI then?) but for automation. And this bug makes plugins like "Copy artifact" to fail. All this results in lots of false build failures. Since people cant really do anything about these build failures they tend to start just to ignore "crazy Jenkins". And this ruins whole concept.

I made a copy of a broken project and the copy seems to work.
Edit: Renaming the copy broke it, but renaming back again gave the history back.

For reference, we're seeing this issue under 1.486, on a Maven job running exclusively on the master. Other apparently identically set up Maven jobs (also running on the master) don't exhibit the same problem, however.

As a possibly-related issue, the jobs where builds disappear have also shown just build status vanishing as well - several early builds had test failures, and every now and then those builds turn up as blue (before eventually vanishing entirely); in both cases, reloading configuration from disk temporarily resolves the issue.

Also seeing this on 1.498. Linux master. Win2K8 slave.

Same issue on 1.493. Main Jenkins on Windows Server 2008 R2 with 1 child node with same OS. Reload Configuration from Disk fixed the issue at least for now. I also noticed that only the builds running on the child node lost their history, the builds on the master were OK.

We have the same problem with 1.499. It happens very frequently with the individual matrix builds. It happens so fast that we run a job, click on the console for the section of the matrix, and IM it to someone else, and by the time they click the link, it's gone.

I don't undertand why this is still an issue, and the issue hasn't even received as much of a comment from someone. This is a huge problem. As a previous commenter stated, it makes people who use Jenkins blame Jenkins for more and more problems. I'm trying my best at the office to keep Jenkins from becoming the scapegoat, but it's bugs like this that make people trust it less and less.

Ubuntu Server 12.04 - Tomcat7 Container.

We experience similar issue as joelj mentioned. For regular jobs build history is kept much longer while for matrix jobs it tends to disappear randomly, even right after build completes. Sometimes there's a link for the build in history on master but not on slaves, sometimes it's gone from both nodes, sometimes there's a link but trying to access it returns 404.
Even reloading configuration makes no difference here. Running on Windows Server 2008 x64, Tomcat7.
Is there a way to raise priority on this issue? It is a real blocker especially in terms of keeping tests historical data - we get an email that something failed but it's extremely hard to trace down what was it if there's no history.

Rearranged links a bit as this issue was marked as duplicate of newer issue that didn't get as much attention...

We're using 1.492. Suddenly, builds #1 to #9 disappeared. After a day or two we decided to launch a build using a different user account. Now the builds do show up, but only starting at #10. I agree with making this bug a blocker.

Does anyone know version where this bug wasnt introduced yet?

Same problem here, with 1.498 (powered by Tomcat 7.0.35) under openSUSE Linux.
I noticed this problem appears for jobs built on agents.

@Nickolay Martinov: It's been happening to us ever since we upgraded to the Lazy Loading patch (1.485).

I'm wondering if this is due to the failure to re-load of an individual build history in AbstractLazyLoadRunMap.java.

Specifically the search(int, Direction) method does a binary search looking for a specific build. When it finds a match it may have to load() the build record from disk. If this fails then it "silently" removes the build that it tried to load and carries on.

    R r = load(idOnDisk.get(pivot), null);
    if (r==null) {
        // this ID isn't valid. get rid of that and retry pivot
        hi--;
        if (!clonedIdOnDisk) {// if we are making an edit, we need to own a copy
            idOnDisk = new SortedList<String>(idOnDisk);
            clonedIdOnDisk = true;
        }
        idOnDisk.remove(pivot);
        continue;
    }

Assuming that the failure to load is a (unknown) transient error then that would cause the build to disappear but it would be re-loaded when jenkins is restarted and the on-disk records scanned again.

I haven't seen this failure mode so I'm not able to test directly. If someone is able/willing to take a debug build of the latest jenkins I'll try to find time to add some additional debug logging to see if we can prove/disprove this theory.

Same here with 1.499, reload from disk consistently clears it, but hardly an option for automated build chains. Our setup is client/server with 5 slaves.

Same problem on 1.498 version (Linux) - very annoying bug.

Sorry Jesse, I'm assigning this to you so that some more core devs are aware of this one...

Does anyone have any clue how to reproduce this from scratch?

There are intimations that this is a regression from lazy loading (JENKINS-8754), yet this was originally filed against an older Jenkins version, so it is possible there are two or more unrelated bugs being lumped together here.

I am using 1.493, and I can repro this just by renaming a job.
I am suspicious this could happen also by changing anything in the job config (but this would have to be verified)

I fix that just by restarting Jenkins http://IP:8080/restart
The history is back with all the jobs.

For us it's just random since we do not (and cant) rename jobs. No particular conditions were noted. Right now it's ok but with couple of builds on any jobs history starts disappearing; reload configuration from disk and builds are back. Since copy artifacts plugin affected, i believe this is not a UI problem. We extensively use matrix projects and ssh slaves with matrix tie parent plugin (dont know if this matters). Downgraded back to 1.463 and this problem disappeared.

Same main usage for us:

• heavy use of "copy artifacts" plugin,
• matrix projects (with "Matrix tie parent" plugin)
• ssh slaves
  At the beginning, we thought indeed this was related to renaming the build job. But the problem also occurs for example when modifying the slaves in the configuration matrix.
  But sometimes, it does occur with free-style (not multi-configuration) jobs too.

Also experiencing this in 1.499 on RHEL.
Reloading configuration from disk seems to solve it.

Can't find any pattern to reproduce this, and the logs doesn't say anything.
Voodoo

I've seen it regularly with renamed jobs. We have heavy use of copy artifacts, no matrix use, several ssh slaves. Almost all free-style jobs (though may have a maven one in there too).

Running on fc17 x86_64.

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?

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.

As described above, this problem seems to be fixed in 1.505 (with 42ee6113b7beff8dccba48593cefe0ad23636051).

But I am so annoyed with this problem that I wrote a plugin to fix the problem in multi-configuration projects.
https://github.com/ikedam/quickfix15156

This may be useful for those that want to fix this problem immediately, or those that do not want to update Jenkins in some reasons.

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.