|
||||||||
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
- [JIRA] (JENKINS-3265) Reload Configuratio... m...@favoritemo.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... m...@favoritemo.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... jeremy.fr...@psion.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... m...@favoritemo.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... m...@favoritemo.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... jeremy.fr...@psion.com (JIRA)
- [JIRA] (JENKINS-3265) Reload Configu... martin.danjo...@gmail.com (JIRA)
POSTing config.xml, which looks like it goes through AbstractItem.doConfigDotXml(), has similar behavior to the reload case as near as I can tell, which is to just load whatever exists in the stored state on disk (in the case of POSTing config.xml, that's whatever you just POSTed) without writing any information into the build.xml for the build numbers which might currently be in progress. So that wouldn't be affected by my change at present. I'm still trying to figure out what the other code paths are doing that is different, but it might be that the answer is "nothing in particular", and in so doing are maintaining their in-memory view of the current Jenkins object graph which contains the running builds.
We don't use the POST of config.xml here but I could add the same logic in to write out the build.xml (and therefore the running build state) for running builds of that job when the POST occurs, which should accomplish the same end for that usage. I'm more interested to know what people think about the general idea about writing the build.xml state out to disk for non-terminated builds. It seems like an eminently reasonable idea to me, but changing that assumption will probably require other changes. Another possibility that I haven't explored is somehow preserving the portion of the Jenkins object graph that contains the running job information, but that would require some gymnastics around saving the RunMap objects off of the Jobs before dumping them and reloading them, but then we'd have to update all the references to point the Runs at the new Job objects and so on. That feels at least as dangerous to me as persisting the state of non-terminated builds.