Community
Participate
Working Groups
Build Identifier: 2.2.1 When reloading the Hudson configuration from disk the status of some builds is lost. These builds only show the first build ever run for the job. So far I have been unable to determine which job parameters lead to loss of status after reload. The standard jobs (git based checkout, archiving all builds) seem to work just fine. But we have several jobs derived from the central git checkout job. And those have no source repository attached and builds are kept for 5 days and to a maximum of 10 builds. Changing the archival setting of these jobs does not seem to change anything. In fact the archival setting does not seem to take effect at all. Currently the jobs keep all the builds. Reproducible: Always Steps to Reproduce: 1. Create new hudson job 2. Execute bash command "sleep 5m" and start job. 3. While executing, go to manage hudson > reload configuration from disk. 4. Hudson will restart. 5. Build will show execution, but fail to have any information about build. 6. Executing new build shows new build information but ignores previous results.
Just wanted to add a little more info: You will not see the 1st build job but after a few minutes and another hudson configs reload, the first build job will show up again (the log file is always there, it doesn't get removed). Also, after you reload the Hudson configuration, you will see the Hudson job running on the main page but if you click on the progress bar you will get a 404.
With the schedule tight to the release of Kepler we are concentrating on new features in Hudson. The bugs assigned for fixing in 3.0.2 will now be fixed as part of the 3.1.0 release due June 26th. Please raise anything you think to be too important to wait by adding a comment to the bug.
This is not important but I found a forum post about this: http://www.eclipse.org/forums/index.php/t/470326/
My take on fixing this issue is - A dialog should appear to confirm reloading - I think the best policy is to put Hudson in quiet mode, that is waiting to finish all the running jobs but no scheduling of new jobs. Once all the jobs are done reload - Though I'm not in favor, but we could have a checkbox saying abort all jobs. This extreme measure is only if there is an assurance Hudson is messed up beyond the benefit of running all jobs and only solution is quickly reload the configuration.
Bulk defer from 3.1.0 & flagging as admin improvement
