Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15156

Builds disappear from build history after completion

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: core
    • Labels:
    • Environment:
      Jenkins 1.477.2
      Master and Slaves Windows Server 2008 r2
      (Also on Jenkins 1.488 Windows Server 2008)
    • Similar Issues:

      Description

      We have recently noticed builds disappearing from the "Build History" listing on the project page. Developer was watching a build, waiting for it to complete and said it disappeared after it finished. Nothing was noted in any of the logs concerning that build.
      The data was still present on the disk and doing a reload from disk brought the build back. We have other automated jobs that deploy these builds based on build number, so it is pretty big issue in our environment.
      We are not able to reproduce at this point, but I still wanted to document what was happening.
      I have seen other JIRA issues that look similar, but in those jobs were disappearing after a restart, or upgrade. That is not the case for us. The build disappears after completion, success or failure.

        Attachments

          Issue Links

            Activity

            Hide
            jow J White added a comment -

            I had this problem but after upgrading to Jenkins 1.486 all was back to normal

            Show
            jow J White added a comment - I had this problem but after upgrading to Jenkins 1.486 all was back to normal
            Hide
            tomhe Tomas Hellberg added a comment -

            I have the same problem on Jenkins ver. 1.488. Master is Windows server 2008. History showed correctly after upgrading to 1.488, but disappeared after next build, so now the history is empty. The build is visible during job execution but disappears after completion.

            Show
            tomhe Tomas Hellberg added a comment - I have the same problem on Jenkins ver. 1.488. Master is Windows server 2008. History showed correctly after upgrading to 1.488, but disappeared after next build, so now the history is empty. The build is visible during job execution but disappears after completion.
            Hide
            tomhe Tomas Hellberg added a comment -

            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.

            Show
            tomhe Tomas Hellberg added a comment - 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.
            Hide
            tomhe Tomas Hellberg added a comment -

            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.

            Show
            tomhe Tomas Hellberg added a comment - 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.
            Hide
            tomhe Tomas Hellberg added a comment -

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

            Show
            tomhe Tomas Hellberg added a comment - 12 hours later the history is back. This time without a master restart.
            Hide
            mykro76 D C added a comment -

            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.

            Show
            mykro76 D C added a comment - 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.
            Hide
            derkoe Christian Köberl added a comment -

            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)

            Show
            derkoe Christian Köberl added a comment - 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)
            Hide
            chorn Cameron Horn added a comment -

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

            Show
            chorn Cameron Horn added a comment - Notice this in particular with newly created jobs, where all build history will vanish after a build or two.
            Hide
            anh Anton Haglund added a comment -

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

            Show
            anh Anton Haglund added a comment - I have seen this in 1.486 as well. I renamed a couple of jobs, and after that all history for those jobs disappeared.
            Hide
            fderunes Franck Derunes added a comment -

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

            Show
            fderunes Franck Derunes added a comment - same experience here. I renamed a couple of jobs and the build history disappeared. Restarting the server solves the issue
            Hide
            johno Johno Crawford added a comment -

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

            Show
            johno Johno Crawford added a comment - Those who are able to reproduce the bug, are you running a standalone Jenkins instance or do you have slaves configured?
            Hide
            tkalpina Tatiana Kalpina added a comment - - edited

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

            Show
            tkalpina Tatiana Kalpina added a comment - - edited I reproduced the issue when Job was renamed and was run on slave (was not checked on master)
            Hide
            anh Anton Haglund added a comment -

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

            Show
            anh Anton Haglund added a comment - johno: I have several build slaves configured in my setup.
            Hide
            derkoe Christian Köberl added a comment -

            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.

            Show
            derkoe Christian Köberl added a comment - 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.
            Hide
            nanzalone Nicolas Anzalone added a comment - - edited

            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.

            Show
            nanzalone Nicolas Anzalone added a comment - - edited 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.
            Hide
            tohlsen Tyler Ohlsen added a comment - - edited

            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.

            Show
            tohlsen Tyler Ohlsen added a comment - - edited 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.
            Hide
            wolfg Yong Guo added a comment - - edited

            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.

            Show
            wolfg Yong Guo added a comment - - edited 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.
            Hide
            sogabe sogabe added a comment -

            changed priority to Critical.

            Show
            sogabe sogabe added a comment - changed priority to Critical.
            Hide
            wolfg Yong Guo added a comment -

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

            Show
            wolfg Yong Guo added a comment - (updated) I just upgrade to 1.495, then the history goes back!
            Hide
            damiandixon damian dixon added a comment -

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

            Show
            damiandixon damian dixon added a comment - This is happening with 1.494. Reloading the configuration brings back the build logs.
            Hide
            larrycai Larry Cai added a comment -

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

            Show
            larrycai Larry Cai added a comment - I have this problem in 1.495 as well, master/slave mode
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            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.

            Show
            nickolay_martinov Nikolay Martynov added a comment - 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.
            Hide
            epkaxma Martin Wiklundh added a comment - - edited

            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.

            Show
            epkaxma Martin Wiklundh added a comment - - edited 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.
            Hide
            jchatham jchatham added a comment -

            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.

            Show
            jchatham jchatham added a comment - 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.
            Hide
            peterloron Peter Loron added a comment -

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

            Show
            peterloron Peter Loron added a comment - Also seeing this on 1.498. Linux master. Win2K8 slave.
            Hide
            ivaylo_bratoev Ivaylo Bratoev added a comment -

            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.

            Show
            ivaylo_bratoev Ivaylo Bratoev added a comment - 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.
            Hide
            joelj Joel Johnson added a comment -

            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.

            Show
            joelj Joel Johnson added a comment - 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.
            Hide
            swiniak Andrzej Pasterczyk added a comment -

            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.

            Show
            swiniak Andrzej Pasterczyk added a comment - 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.
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

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

            Show
            nickolay_martinov Nikolay Martynov added a comment - Rearranged links a bit as this issue was marked as duplicate of newer issue that didn't get as much attention...
            Hide
            deepchip Martin d'Anjou added a comment -

            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.

            Show
            deepchip Martin d'Anjou added a comment - 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.
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            Does anyone know version where this bug wasnt introduced yet?

            Show
            nickolay_martinov Nikolay Martynov added a comment - Does anyone know version where this bug wasnt introduced yet?
            Hide
            hgomez Henri Gomez added a comment - - edited

            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.

            Show
            hgomez Henri Gomez added a comment - - edited 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.
            Hide
            joelj Joel Johnson added a comment -

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

            Show
            joelj Joel Johnson added a comment - @Nickolay Martinov: It's been happening to us ever since we upgraded to the Lazy Loading patch (1.485).
            Hide
            oldelvet Richard Mortimer added a comment -

            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.

            Show
            oldelvet Richard Mortimer added a comment - 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.
            Hide
            nneul Nathan Neulinger added a comment - - edited

            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.

            Show
            nneul Nathan Neulinger added a comment - - edited 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.
            Hide
            jvanbouchaute Jurgen Van Bouchaute added a comment -

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

            Show
            jvanbouchaute Jurgen Van Bouchaute added a comment - Same problem on 1.498 version (Linux) - very annoying bug.
            Hide
            domi Dominik Bartholdi added a comment -

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

            Show
            domi Dominik Bartholdi added a comment - Sorry Jesse, I'm assigning this to you so that some more core devs are aware of this one...
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            fderunes Franck Derunes added a comment -

            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.

            Show
            fderunes Franck Derunes added a comment - 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.
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            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.

            Show
            nickolay_martinov Nikolay Martynov added a comment - 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.
            Hide
            aeschbacher aeschbacher added a comment -

            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.
            Show
            aeschbacher aeschbacher added a comment - 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.
            Hide
            miked michael d added a comment -

            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

            Show
            miked michael d added a comment - 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
            Hide
            nneul Nathan Neulinger added a comment -

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

            Show
            nneul Nathan Neulinger added a comment - 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).
            Hide
            nneul Nathan Neulinger added a comment -

            Running on fc17 x86_64.

            Show
            nneul Nathan Neulinger added a comment - Running on fc17 x86_64.
            Hide
            hx_unbanned Linards L added a comment -

            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 :/

            Show
            hx_unbanned Linards L added a comment - 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 :/
            Hide
            ivaylo_bratoev Ivaylo Bratoev added a comment -

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

            Show
            ivaylo_bratoev Ivaylo Bratoev added a comment - As a matter of fact I renamed these builds some time ago as well... This might be one part of the issue.
            Hide
            richardm_tx Richard Merrill added a comment -

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

            Show
            richardm_tx Richard Merrill added a comment - 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...
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - 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 ...
            Hide
            jenkinsuserfrance jenkinsuserfrance jenkinsuserfrance added a comment -

            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.

            Show
            jenkinsuserfrance jenkinsuserfrance jenkinsuserfrance added a comment - 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.
            Hide
            jtaylor Julian Taylor added a comment -

            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.

            Show
            jtaylor Julian Taylor added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - 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+.
            Hide
            bbonn bbonn added a comment -

            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?

            Show
            bbonn bbonn added a comment - 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?
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            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.

            Show
            nickolay_martinov Nikolay Martynov added a comment - 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.
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - Is there any code coverage taken, that is executed WITH and WITHOUT this lazy loading implementation?
            Show
            jglick Jesse Glick added a comment - https://github.com/jenkinsci/jenkins/pull/688
            Hide
            hx_unbanned Linards L added a comment -

            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

            Show
            hx_unbanned Linards L added a comment - 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
            Hide
            hx_unbanned Linards L added a comment -

            Another one ...

            Show
            hx_unbanned Linards L added a comment - Another one ...
            Hide
            johno Johno Crawford added a comment -

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

            Show
            johno Johno Crawford added a comment - @jglick can you confirm whether or not the fix will make it for 1.501?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            joyalbin Albin Joy added a comment -

            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.

            Show
            joyalbin Albin Joy added a comment - 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.
            Hide
            jaystan Jason Stanley added a comment -

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

            Show
            jaystan Jason Stanley added a comment - I have encountered this same problem. Jenkins 1.499 Server CentOS 6.2 Restarting Jenkins shows missing builds.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            dogfood dogfood added a comment -

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            dogfood dogfood added a comment -

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - 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. "
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            dogfood dogfood added a comment -

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - hmm. Is there any hope to get this fix-set STABLE?
            Hide
            johno Johno Crawford added a comment -

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

            Show
            johno Johno Crawford added a comment - Current build stability is STABLE, see https://ci.jenkins-ci.org/job/jenkins_main_trunk/ .
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - Linked another one that might be connected to this issue / side-effects...
            Hide
            richardm_tx Richard Merrill added a comment -

            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.

            Show
            richardm_tx Richard Merrill added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

            @richardm_tx: 1.502 I think.

            Show
            jglick Jesse Glick added a comment - @richardm_tx: 1.502 I think.
            Hide
            richardm_tx Richard Merrill added a comment -

            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.

            Show
            richardm_tx Richard Merrill added a comment - 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.
            Hide
            oldelvet Richard Mortimer added a comment -

            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

            Show
            oldelvet Richard Mortimer added a comment - 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
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            Could anyone please confirm that issue is fixed?

            Show
            nickolay_martinov Nikolay Martynov added a comment - Could anyone please confirm that issue is fixed?
            Hide
            hx_unbanned Linards L added a comment -

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

            Show
            hx_unbanned Linards L added a comment - 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 ...
            Hide
            lmgrill Larry Grill added a comment - - edited

            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.

            Show
            lmgrill Larry Grill added a comment - - edited 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            dogfood dogfood added a comment -

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            pedroreis pedro reis added a comment -

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

            Show
            pedroreis pedro reis added a comment - Sorry, but failed builds still disappear on Jenkins v1.502...
            Hide
            pedroreis pedro reis added a comment -

            Still disappearing at 1.502 (at least for failed builds)

            Show
            pedroreis pedro reis added a comment - Still disappearing at 1.502 (at least for failed builds)
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            dogfood dogfood added a comment -

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            nickolay_martinov Nikolay Martynov added a comment -

            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.

            Show
            nickolay_martinov Nikolay Martynov added a comment - 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.
            Hide
            finerrecliner Dave F added a comment -

            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.

            Show
            finerrecliner Dave F added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            ikedam ikedam added a comment -

            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.

            Show
            ikedam ikedam added a comment - 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.
            Hide
            ikedam ikedam added a comment -

            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.

            Show
            ikedam ikedam added a comment - 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.
            Hide
            jglick Jesse Glick added a comment - - edited

            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.

            Show
            jglick Jesse Glick added a comment - - edited 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 .
            Hide
            richardm_tx Richard Merrill added a comment -

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

            Show
            richardm_tx Richard Merrill added a comment - This issue number doesn't show up in the changelog for version 1.505 or 1.506. Is it really fixed?
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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 .
            Hide
            dogfood dogfood added a comment -

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

            Result = SUCCESS
            Jesse Glick : c596ed517c3f67bff172cfa0d3ac62e01d35dd54
            Files :

            • changelog.html
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2362 JENKINS-15156 Noting. (Revision c596ed517c3f67bff172cfa0d3ac62e01d35dd54) Result = SUCCESS Jesse Glick : c596ed517c3f67bff172cfa0d3ac62e01d35dd54 Files : changelog.html
            Hide
            strips Stian Indal Haugseth added a comment -

            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.

            Show
            strips Stian Indal Haugseth added a comment - 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.
            Hide
            bavoiculescu Voiculescu Bogdan Alexandru added a comment -

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

            Show
            bavoiculescu Voiculescu Bogdan Alexandru added a comment - I confirm regression! please re-open this. Is getting annoying.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            alex01ves Alex Vesely added a comment - - edited

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

            Show
            alex01ves Alex Vesely added a comment - - edited Filed https://issues.jenkins-ci.org/browse/JENKINS-17265 , as the issue still persists on 1.506.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            kevinhcross Kevin Cross added a comment -

            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?

            Show
            kevinhcross Kevin Cross added a comment - 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?
            Hide
            pedroreis pedro reis added a comment -

            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

            Show
            pedroreis pedro reis added a comment - 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
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            vladichko Vlad Aginsky added a comment -

            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.

            Show
            vladichko Vlad Aginsky added a comment - 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.
            Hide
            vladichko Vlad Aginsky added a comment -

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

            Show
            vladichko Vlad Aginsky added a comment - Jessie, it still happens, see my separate comment in thread. Do you ensist than new issue has to filed here?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - BTW one fix here was in Promoted Builds 2.10, not core.
            Hide
            vladichko Vlad Aginsky added a comment -

            can we get it to core?

            Show
            vladichko Vlad Aginsky added a comment - can we get it to core?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            hgomez Henri Gomez added a comment -

            Fix assignee

            Show
            hgomez Henri Gomez added a comment - Fix assignee
            Hide
            odklizec Pavel Kudrys added a comment - - edited

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

            Show
            odklizec Pavel Kudrys added a comment - - edited 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).
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            odklizec Pavel Kudrys added a comment -

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

            Show
            odklizec Pavel Kudrys added a comment - @Jesse thanks for the reply. OK, I will keep an eye on this issue.
            Hide
            rlagoue rlagoue added a comment -

            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.

            Show
            rlagoue rlagoue added a comment - 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.
            Hide
            jwilso_27 Jon Wilson added a comment -

            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.

            Show
            jwilso_27 Jon Wilson added a comment - 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.
            Hide
            ntshako Hannes Kogler added a comment -

            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?

            Show
            ntshako Hannes Kogler added a comment - 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?
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            byronbrummer Byron Brummer added a comment - - edited

            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.

            Show
            byronbrummer Byron Brummer added a comment - - edited 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.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            binary binary added a comment -

            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.

            Show
            binary binary added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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).
            Hide
            jean Jean Helou added a comment -

            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.

            Show
            jean Jean Helou added a comment - 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.
            Hide
            jazzyjayx Jay Spang added a comment -

            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.

            Show
            jazzyjayx Jay Spang added a comment - 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.
            Hide
            vladichko Vlad Aginsky added a comment - - edited

            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.

            Show
            vladichko Vlad Aginsky added a comment - - edited 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            bavoiculescu Voiculescu Bogdan Alexandru added a comment -

            Great news, Jesse! Looking forward for next version!

            Show
            bavoiculescu Voiculescu Bogdan Alexandru added a comment - Great news, Jesse! Looking forward for next version!
            Hide
            vladichko Vlad Aginsky added a comment - - edited

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

            Show
            vladichko Vlad Aginsky added a comment - - edited Jesse, whas is released? in what version? I still observe it in 1.541
            Hide
            vladichko Vlad Aginsky added a comment -

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

            Show
            vladichko Vlad Aginsky added a comment - I still see it in 1.541 builds just dissapear ~once a week. Reload configuration helps.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            arvindramalingam Arvind Ramalingam added a comment -

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

            Show
            arvindramalingam Arvind Ramalingam added a comment - 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??
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - @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.
            Hide
            arvindramalingam Arvind Ramalingam added a comment -

            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.

            Show
            arvindramalingam Arvind Ramalingam added a comment - 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.
            Hide
            arvindramalingam Arvind Ramalingam added a comment -

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

            Show
            arvindramalingam Arvind Ramalingam added a comment - I see the builds on the server but not on the UI...The trend on the UI also does not show the history
            Hide
            jglick Jesse Glick added a comment -

            Then you might be seeing JENKINS-18678.

            Show
            jglick Jesse Glick added a comment - Then you might be seeing JENKINS-18678 .
            Hide
            arvindramalingam Arvind Ramalingam added a comment -

            Thanks Jesse..Ill follow up JENKINS-18678.

            Show
            arvindramalingam Arvind Ramalingam added a comment - Thanks Jesse..Ill follow up JENKINS-18678 .
            Hide
            docwhat Christian Höltje added a comment - - edited

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

            Show
            docwhat Christian Höltje added a comment - - edited 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'.
            Hide
            danielbeck Daniel Beck added a comment -

            Christian Höltje:

            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?

            Show
            danielbeck Daniel Beck added a comment - Christian Höltje : 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?
            Hide
            docwhat Christian Höltje added a comment -

            Ugh.

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

            Show
            docwhat Christian Höltje added a comment - Ugh. I'm sorry Daniel Beck , I meant 'build'. I'll re-edit that comment to be correct.
            Hide
            docwhat Christian Höltje added a comment -

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

            Show
            docwhat Christian Höltje added a comment - 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...
            Hide
            danielbeck Daniel Beck added a comment -

            Christian:

            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.

            It's an independent deliberately slow process only loading one build per 10 seconds to not be too expensive in terms of disk IO.

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

            Detecting two builds with same number is covered by the OutOfOrderBuildMonitor (JENKINS-22631) in 1.561+ and 1.554.1+.

            I had the same problem a few times over the last 8 months or so. It is definitely a different issue from the one reported here, as no two builds with the same number will be loaded by Jenkins – so the 'Reload from disk' cannot help here.

            I suggest you open a new issue and link it to this one.

            Show
            danielbeck Daniel Beck added a comment - Christian: 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. It's an independent deliberately slow process only loading one build per 10 seconds to not be too expensive in terms of disk IO. 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>) Detecting two builds with same number is covered by the OutOfOrderBuildMonitor ( JENKINS-22631 ) in 1.561+ and 1.554.1+. I had the same problem a few times over the last 8 months or so. It is definitely a different issue from the one reported here, as no two builds with the same number will be loaded by Jenkins – so the 'Reload from disk' cannot help here. I suggest you open a new issue and link it to this one.
            Hide
            docwhat Christian Höltje added a comment -

            So we just got more builds missing from the history that are well formed (e.g. my checker shows no problem and I can't see any problems from examining things).

            So I guess the duplicate builds (aka JENKINS-23130) are not causing this problem.

            Show
            docwhat Christian Höltje added a comment - So we just got more builds missing from the history that are well formed (e.g. my checker shows no problem and I can't see any problems from examining things). So I guess the duplicate builds (aka JENKINS-23130 ) are not causing this problem.
            Hide
            docwhat Christian Höltje added a comment -

            Actually JENKINS-23130 is likely a symptom to this problem.

            We use GerritTrigger a lot, I'm wondering if it has something to do with this.

            Anyway, we just watched this happen in the wild...

            We had build 482 at 3:04pm.

            We then kicked off builds 483, 484, 485 at 4:09am, 4:12am, and 4:28 all submitted by Gerrit Trigger.

            483, 484, and 485 weren't showing up in the Jenkins Web UI but they were well formed on disk.

            We then did a "Query and Trigger Gerrit Patches" and a new 483 was kicked off (stealing the build number from the previous 483).

            Some how the RunMap lost track of the previous 483, 484, and 485.

            And something between 485 and "Query and Trigger Gerrit Patches" caused nextBuildNumber to be lost (going back to 483 matching the Jenkins UI only showing up to build 482).

            Show
            docwhat Christian Höltje added a comment - Actually JENKINS-23130 is likely a symptom to this problem. We use GerritTrigger a lot, I'm wondering if it has something to do with this. Anyway, we just watched this happen in the wild... We had build 482 at 3:04pm. We then kicked off builds 483, 484, 485 at 4:09am, 4:12am, and 4:28 all submitted by Gerrit Trigger. 483, 484, and 485 weren't showing up in the Jenkins Web UI but they were well formed on disk. We then did a "Query and Trigger Gerrit Patches" and a new 483 was kicked off (stealing the build number from the previous 483). Some how the RunMap lost track of the previous 483, 484, and 485. And something between 485 and "Query and Trigger Gerrit Patches" caused nextBuildNumber to be lost (going back to 483 matching the Jenkins UI only showing up to build 482).
            Hide
            docwhat Christian Höltje added a comment -

            So I just used the debugger "fix" a nextBuildNumber inside assignBuildNumber on the fly...

            on disk was ... 55, 56, 57 – However, the Jenkins Web UI showed only 55.

            I changed the nextBuildNumber to 58, and now the Web UI is showing 55 and 58.

            I'm beginning to think something is monkeying around with the list of builds (aka RunMap)...

            Show
            docwhat Christian Höltje added a comment - So I just used the debugger "fix" a nextBuildNumber inside assignBuildNumber on the fly... on disk was ... 55, 56, 57 – However, the Jenkins Web UI showed only 55. I changed the nextBuildNumber to 58, and now the Web UI is showing 55 and 58. I'm beginning to think something is monkeying around with the list of builds (aka RunMap )...
            Hide
            docwhat Christian Höltje added a comment -

            On IRC Steven Christou said that he tracked this down to GerritTrigger...

            Specifically, his steps to reproduce are to "Reload Configuration from Disk" and then kick off a Gerrit build.

            The nextBuildNumber was new to GerritTrigger author rsandell; "It could have something to do with cancel previous patchsets, but I'm just guessing".

            I'm also fairly certain its happening to us even without "Reload Configuration from Disk" because we normally don't use that (we've been using Jenkins since the days when build info would be lost and are afraid of it).

            rsandell mentioned that core not sending a start/stop signal to the triggers when a reload from disk is performed makes it very hard for him to make GerritTrigger behave better.

            Show
            docwhat Christian Höltje added a comment - On IRC Steven Christou said that he tracked this down to GerritTrigger... Specifically, his steps to reproduce are to "Reload Configuration from Disk" and then kick off a Gerrit build. The nextBuildNumber was new to GerritTrigger author rsandell ; "It could have something to do with cancel previous patchsets, but I'm just guessing". I'm also fairly certain its happening to us even without "Reload Configuration from Disk" because we normally don't use that (we've been using Jenkins since the days when build info would be lost and are afraid of it). rsandell mentioned that core not sending a start/stop signal to the triggers when a reload from disk is performed makes it very hard for him to make GerritTrigger behave better.
            Hide
            vladichko Vlad Aginsky added a comment -

            Guys i also see it with gerrit builds. there is no one assigned to this.

            Show
            vladichko Vlad Aginsky added a comment - Guys i also see it with gerrit builds. there is no one assigned to this.
            Hide
            danielbeck Daniel Beck added a comment -

            It appears this is a known issue with Gerrit Trigger. See yesterday's IRC log, 23:05-23:25.

            Show
            danielbeck Daniel Beck added a comment - It appears this is a known issue with Gerrit Trigger. See yesterday's IRC log , 23:05-23:25.
            Hide
            vladichko Vlad Aginsky added a comment - - edited

            assigned to Robert Sandell (id: rsandell) since it seems to be gerrit plugin issues

            Show
            vladichko Vlad Aginsky added a comment - - edited assigned to Robert Sandell (id: rsandell) since it seems to be gerrit plugin issues
            Hide
            oldelvet Richard Mortimer added a comment -

            Please open a new JIRA issue to track the Gerrit Trigger issue. This is definitely a different issue to the original bug although it has similar symptoms.

            It gets too confusing if we overload one issue that has been resolved for over a year.

            Show
            oldelvet Richard Mortimer added a comment - Please open a new JIRA issue to track the Gerrit Trigger issue. This is definitely a different issue to the original bug although it has similar symptoms. It gets too confusing if we overload one issue that has been resolved for over a year.
            Hide
            docwhat Christian Höltje added a comment -

            I created issue JENKINS-23152 for GerritTrigger.

            Show
            docwhat Christian Höltje added a comment - I created issue JENKINS-23152 for GerritTrigger.
            Hide
            docwhat Christian Höltje added a comment -

            Okay, I have a case that isn't GerritTrigger related. The job uses just Git.

            I get this output from my job checker:

            jenkins-job-checker output
            myjob-release:
             Problem: STOLEN: The date build myjob-release/builds/2014-05-23_09-21-18 had its number stolen by myjob-release/builds/4113 -> 2014-05-23_09-36-18
             Problem: STOLEN: The date build myjob-release/builds/2014-05-23_09-21-18 had its number stolen by myjob-release/builds/4113 -> 2014-05-23_09-36-18
             Proposal: Relink 4113 to myjob-release/builds/2014-05-23_09-21-18
             Proposal: Archive newer build myjob-release/builds/2014-05-23_09-36-18
             Proposal: Relink 4113 to myjob-release/builds/2014-05-23_09-21-18
             Proposal: Archive newer build myjob-release/builds/2014-05-23_09-36-18
            

            So something else is holding on to an old job reference someplace.

            Show
            docwhat Christian Höltje added a comment - Okay, I have a case that isn't GerritTrigger related. The job uses just Git. I get this output from my job checker: jenkins-job-checker output myjob-release: Problem: STOLEN: The date build myjob-release/builds/2014-05-23_09-21-18 had its number stolen by myjob-release/builds/4113 -> 2014-05-23_09-36-18 Problem: STOLEN: The date build myjob-release/builds/2014-05-23_09-21-18 had its number stolen by myjob-release/builds/4113 -> 2014-05-23_09-36-18 Proposal: Relink 4113 to myjob-release/builds/2014-05-23_09-21-18 Proposal: Archive newer build myjob-release/builds/2014-05-23_09-36-18 Proposal: Relink 4113 to myjob-release/builds/2014-05-23_09-21-18 Proposal: Archive newer build myjob-release/builds/2014-05-23_09-36-18 So something else is holding on to an old job reference someplace.
            Hide
            oldelvet Richard Mortimer added a comment -

            I suggest logging that as a new issue and linking it to this one. Irrespective of whether or not it is related the comments trail/information is just too big/complex on this issue.

            Show
            oldelvet Richard Mortimer added a comment - I suggest logging that as a new issue and linking it to this one. Irrespective of whether or not it is related the comments trail/information is just too big/complex on this issue.
            Hide
            oldelvet Richard Mortimer added a comment -

            Many issues could have similar symptoms. The root cause of the original issue has been fixed. Please log any further occurrences in a new issue.

            Show
            oldelvet Richard Mortimer added a comment - Many issues could have similar symptoms. The root cause of the original issue has been fixed. Please log any further occurrences in a new issue.
            Hide
            andy0815 Andreas W added a comment -

            This bug is really annoying. I don't know what the root cause was here and how many bugs have the same symptom. It also happens again in Jenkins 1.570 and 1.571 on Windows Server 2008. Build occur after random time they disappear, symbolic links go away but builds are on disk...

            Show
            andy0815 Andreas W added a comment - This bug is really annoying. I don't know what the root cause was here and how many bugs have the same symptom. It also happens again in Jenkins 1.570 and 1.571 on Windows Server 2008. Build occur after random time they disappear, symbolic links go away but builds are on disk...
            Hide
            kveretennicov Konstantin Veretennicov added a comment -

            Similar symptoms of "disappearing builds", but different root cause.

            Show
            kveretennicov Konstantin Veretennicov added a comment - Similar symptoms of "disappearing builds", but different root cause.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            test/src/test/groovy/hudson/model/AbstractProjectTest.groovy
            http://jenkins-ci.org/commit/jenkins/389a565de417170f586830ee9fa7a7ec9749fc68
            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.

            (cherry picked from commit 85e9e126773c0bb20a8529a2e6591dde17d7e209)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/test/groovy/hudson/model/AbstractProjectTest.groovy http://jenkins-ci.org/commit/jenkins/389a565de417170f586830ee9fa7a7ec9749fc68 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. (cherry picked from commit 85e9e126773c0bb20a8529a2e6591dde17d7e209)
            Hide
            ashah Andy Shah added a comment - - edited

            Recently upgraded from Jenkins 1.540 to latest release 1.605, After upgrade noticed build history for all the Jenkins jobs were gone. I currently have close to 350 jobs and losing history is really pain. Had to downgrade to 1.540 to restore the environment.

            Update: Tried "Reload Configuration" option but no luck.

            Show
            ashah Andy Shah added a comment - - edited Recently upgraded from Jenkins 1.540 to latest release 1.605, After upgrade noticed build history for all the Jenkins jobs were gone. I currently have close to 350 jobs and losing history is really pain. Had to downgrade to 1.540 to restore the environment. Update: Tried "Reload Configuration" option but no luck.
            Hide
            danielbeck Daniel Beck added a comment -

            After upgrade noticed build history for all the Jenkins jobs were gone

            Completely unrelated issue.

            Show
            danielbeck Daniel Beck added a comment - After upgrade noticed build history for all the Jenkins jobs were gone Completely unrelated issue.
            Hide
            novaind ang chang added a comment -

            Hi,
            I am facing the same problem on Jenkins 1.555 on windows. Sometime build history item will disappear when running and leave the job unfinished.
            So I am wondering this bug is fixed on which version? Can I avoid this problem by upgrading to new version?

            Show
            novaind ang chang added a comment - Hi, I am facing the same problem on Jenkins 1.555 on windows. Sometime build history item will disappear when running and leave the job unfinished. So I am wondering this bug is fixed on which version? Can I avoid this problem by upgrading to new version?
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Johno Crawford
            Path:
            test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
            http://jenkins-ci.org/commit/jenkins-test-harness/6856f5db18f4295043438e4018e95bd454bdd0ca
            Log:
            JENKINS-15156 Refactored fix.

            Originally-Committed-As: fe95fc53f891542e63e24a64c0b7add60ac91c64

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Johno Crawford Path: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java http://jenkins-ci.org/commit/jenkins-test-harness/6856f5db18f4295043438e4018e95bd454bdd0ca Log: JENKINS-15156 Refactored fix. Originally-Committed-As: fe95fc53f891542e63e24a64c0b7add60ac91c64
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java http://jenkins-ci.org/commit/jenkins-test-harness/9933530be8674c316f6be0fafc71c9239c0755f7 Log: JENKINS-15156 Class loading errors can result from OOME if you are not careful. Originally-Committed-As: 74e6409a06531144316f2e36bdc0b069de52b94d

              People

              • Assignee:
                Unassigned
                Reporter:
                bbonn bbonn
              • Votes:
                61 Vote for this issue
                Watchers:
                116 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: