-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.74
Job-Config-History 2.18
A large series of changes to a group of jobs was implemented in part by editing the job config.xml files directly followed by a "Reload Configuration From Disk" in the Manage Jenkins area.
I suspected this might be 'confusing' to the Job Config History plugin, so I went to the job's Configure page (intending to save the configuration without changes to create a new history entry) - but the configuration was clearly the old configuration prior to edits.
It would be nice if there was a way to clue the Job Config History plugin that the config.xml has changed outside of the job's Configuration page. From a user's perspective (I have no idea how Jenkins is implemented) there are a couple of ways this could happen:
1) The job config history could fire something off when "Reload from disk" occurs to compare job configs and update (create a new history entry for) any changed job configs, assigning the new version to the user executing the reload.
2) There could be a button/link on the job page that basically says "Create a new job config from whatever is on disk" - effectively a "single job reload configuration" that creates a new history entry.
3) When the Configuration link is pressed, somehow Jenkins seems to know to take the "old" history and not the one currently on disk. It could put up some kind of warning dialog and allow users to choose whether to start from the current on-disk configuration or the last-saved configuration.
I could find no documentation that cautioned about Job Config History's not being able to handle "Reload". (I hope I didn't miss it!) I recognize this is not the typical use case but I clearly Jenkins understands some users manipulate raw config XML (or it wouldn't provide the Reload button!). Therefore the Job Config History plugin ought to address this case - even if initially it is to simply document that this use case is not currently supported.
This is all cool stuff. I'm not trying to say something's bad, just suggesting that something could be improved.
Thank you for your suggestions.
JobConfigHistory gets notified by listeners provided by the Jenkins core. Each time save() gets called, JobConfigHistory gets notified and performs checks. It does not get notified by load() calls.
1) JobConfigHistory doesn't know anything about jobs. It would be a huge task for JobConfigHistory to check the config files of each job and compare them with the persisted history. Especially in environments with thousands of jobs or so, this task would lead to a heavy system load.
2) A reload button for single job configs should be part of the Jenkins core (or maybe an other plugin), but not of JobConfigHistory. Well, a second button as part of JobConfigHistory to check if the current config is the same as the last history entry and if not, create a new entry, could get realized. But I wouldn't be very lucky about that. There might be a onLoaded(Item item) listener in the core JobConfigHistory could listen to. At the moment there's just a onLoaded() listener that notifies when all items are loaded.
3) AFAIK Jenkins loads all config information into memory during startup. So it uses always these information until save() or load() get performed. A warning dialog could also be part of the Jenkins core or a plugin to check this but I think that JobConfigHistory isn't the right place to do this.