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

Reload Configuration from Disk (or POSTing config.xml) loses info on running builds

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Platform: PC, OS: Windows XP

      Executing the "Reload Configuration from Disk" while builds are running causes
      information about those builds to be lost.

      POSTing a new configuration to /job/JOBNAME/config.xml also causes the exact same problem. Yet editing job configuration interactively using the web form does not show the problem.

      I had two builds running when I reloaded configuration to pick up manual changes
      to one project (not running a build) config.xml file. When the browser
      refreshed, the builds were still shown as actively building in the Build
      Executor Status frame but the status indicators were no longer blinking and the
      project pages did not show any builds running for those projects.

      It appears that part of Hudson thought that the builds had been canceled because
      they were queued, blocked by themselves. The original builds appeared to
      finsish normally and then the queued builds ran. There was no record of the
      original build that had been running when the config reloaded.

      Note: If Jenkins is completely restarted, by shutting down and starting up the service, the missing build re-appears. (Of course, doing that each time is unacceptable, just trying to help focus the debugging.)

          [JENKINS-3265] Reload Configuration from Disk (or POSTing config.xml) loses info on running builds

          pcampbell created issue -

          shurikgefter added a comment -

          I have the same problem.

          I checked it with Hudson #3.369 and #3.383

          How reproduce the problem:

          1) Define the free-style project.
          2) Add command sleep 300
          3) Run this job.
          4) When this job running execute "Reload Configuration from Disk"
          5) Click on progress bar of running job ( console output )
          6) Get page 404 error
          7) In the history of this job I can't see the current running execution.

          shurikgefter added a comment - I have the same problem. I checked it with Hudson #3.369 and #3.383 How reproduce the problem: 1) Define the free-style project. 2) Add command sleep 300 3) Run this job. 4) When this job running execute "Reload Configuration from Disk" 5) Click on progress bar of running job ( console output ) 6) Get page 404 error 7) In the history of this job I can't see the current running execution.

          samweiss added a comment -

          Hi

          I too have this problem, and the way I manage my builds, this is getting very troublesome (I have automatic processes to create jobs for me for build branches that are created).

          Any time Hudson reloads configuratons, not only are the info on running builds lost, you have to do another reload configuration once a running job is completed in order for hudson to recognize it.

          Thanks!

          Sam

          samweiss added a comment - Hi I too have this problem, and the way I manage my builds, this is getting very troublesome (I have automatic processes to create jobs for me for build branches that are created). Any time Hudson reloads configuratons, not only are the info on running builds lost, you have to do another reload configuration once a running job is completed in order for hudson to recognize it. Thanks! Sam

          Anne Sullivan added a comment -

          We are also struggling with this problem: it makes it problematic to use the reload from disk option because we have a lot of long-running (>1hr) builds, and we don't want to lose visibility of currently executing jobs.

          Anne Sullivan added a comment - We are also struggling with this problem: it makes it problematic to use the reload from disk option because we have a lot of long-running (>1hr) builds, and we don't want to lose visibility of currently executing jobs.

          Same here.

          In fact, in an attempt to get away of this problem we tried to perform bulk configuration changes on jobs through the CLI jar file by calling get-job, updating it's xml locally and then calling update-job to upload the new config... and the same behaviour occurs with running jobs :/ (more info about this at http://groups.google.com/group/jenkinsci-users/browse_frm/thread/9786fa572e9924b6)

          David Santiago Turiño added a comment - Same here. In fact, in an attempt to get away of this problem we tried to perform bulk configuration changes on jobs through the CLI jar file by calling get-job, updating it's xml locally and then calling update-job to upload the new config... and the same behaviour occurs with running jobs :/ (more info about this at http://groups.google.com/group/jenkinsci-users/browse_frm/thread/9786fa572e9924b6 )
          Uwe Stuehler made changes -
          Link New: This issue is duplicated by JENKINS-10219 [ JENKINS-10219 ]

          samweiss added a comment -

          Is there a status on this bug? It was filed over a year ago, and still repros. It's listed as "major"! Hello????

          samweiss added a comment - Is there a status on this bug? It was filed over a year ago, and still repros. It's listed as "major"! Hello????

          pmv added a comment -

          David - we also switched to using the cli to perform bulk changes. I currently use the following groovy method to make a job isn't running before doing the update:

          public boolean isJobRunning(String jobName) {
          	URL jobDetails = new URL(JENKINS_URL + "/job/" + jobName + "/api/xml?depth=1")
          	SAXParserFactory factory = SAXParserFactory.newInstance()
          	factory.setFeature( "http://apache.org/xml/features/nonvalidating/load-external-dtd", false)
          	def details = new XmlSlurper(factory.newSAXParser()).parse(jobDetails.openStream())
          	String building = details.build.building[0]
          	if(building.equals("true")) {
          		return true
          	}
          	return false
          }
          

          Not really an answer to the original bug, but might help you...

          pmv added a comment - David - we also switched to using the cli to perform bulk changes. I currently use the following groovy method to make a job isn't running before doing the update: public boolean isJobRunning( String jobName) { URL jobDetails = new URL(JENKINS_URL + "/job/" + jobName + "/api/xml?depth=1" ) SAXParserFactory factory = SAXParserFactory.newInstance() factory.setFeature( "http: //apache.org/xml/features/nonvalidating/load-external-dtd" , false ) def details = new XmlSlurper(factory.newSAXParser()).parse(jobDetails.openStream()) String building = details.build.building[0] if (building.equals( " true " )) { return true } return false } Not really an answer to the original bug, but might help you...

          First of all thanks for sharing, pmv.

          The truth is that we switched to the cli tool when we found that we had to stop jenkins to perform bulk configuration changes on xmls due to the problem with reloading the config. But if we have to wait for jobs not to be running for the update to work from the cli, we are losing the advantage we wanted to get from using cli in the first place: the possibility of doing "hot" bulk updates of jobs configurations in a fast way.

          Nevertheless I will have it in mind should we switch back again to the cli approach.

          David Santiago Turiño added a comment - First of all thanks for sharing, pmv. The truth is that we switched to the cli tool when we found that we had to stop jenkins to perform bulk configuration changes on xmls due to the problem with reloading the config. But if we have to wait for jobs not to be running for the update to work from the cli, we are losing the advantage we wanted to get from using cli in the first place: the possibility of doing "hot" bulk updates of jobs configurations in a fast way. Nevertheless I will have it in mind should we switch back again to the cli approach.
          kutzi made changes -
          Link New: This issue is duplicated by JENKINS-7885 [ JENKINS-7885 ]

            kohsuke Kohsuke Kawaguchi
            pcampbell pcampbell
            Votes:
            28 Vote for this issue
            Watchers:
            49 Start watching this issue

              Created:
              Updated:
              Resolved: