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?

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.

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.

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.