Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: core
-
Labels:None
-
Similar Issues:
Description
After a restart, I get complaints from developers that their committed changes have not triggered. On a closer look, it turns out that the builds were already present in the build queue during restart. Saving the queue before restart would be a nice extension...
Attachments
Activity
Seems like it. With the safeRestart thread problems fixed in 1.367, I can confirm that after a safeRestart the build queue is empty.
Can you post steps to reproduce the problem in a new 1.367 install with no added plugins? Thanks.
- Create a 120 sec countdown job
- Set the number of executors to 1
- create two minimal jobs
- start the countdown job
- start the two small jobs
- http://<hudsonserver>/safeRestart
- after restart, the two pending jobs will not have been executed (you can tell by the build number)
thanks.. those steps did reproduce the issue for me.. I'll do some digging.
Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/core/src/main/java/hudson/lifecycle/SolarisSMFLifecycle.java
trunk/hudson/main/core/src/main/java/hudson/lifecycle/UnixLifecycle.java
trunk/hudson/main/core/src/main/java/hudson/model/Hudson.java
trunk/www/changelog.html
http://jenkins-ci.org/commit/33184
Log:
[FIXED JENKINS-6804] call Hudson.cleanUp from lifecycle classes and in Hudson.doSafeExit
so that safeRestart and safeExit propertly cleanup before terminating the process;
in particular, so the contents of the build queue is saved so it can be restored
after restart. Also increased delay before restart from 5 to 10 seconds,
as I saw one build get interrupted at restart in my testing.
Hudson.java:2228 should save the queue contents.. I wonder if cleanUp() is somehow not called for safeRestart? cleanUp is called from WebAppMain.contextDestroyed().