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

job-config-history reverts configuration following Jenkins reload from disk

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 2.74
      Job-Config-History 2.18
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          Hide
          jochenafuerbacher Jochen A. Fürbacher added a comment -

          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.

          Show
          jochenafuerbacher Jochen A. Fürbacher added a comment - 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.
          Hide
          ianw Ian Williams added a comment - - edited

          wrt:

          "1) ...  It would be a huge task for JobConfigHistory to check the config files of each job",

          I suppose huge is relative, but we have over 5500 jobs on system.

          jobInfo = Jenkins.instance.getAllItems(AbstractItem.class).collect { item ->
           {{ XmlFile config = item.getConfigFile();}}
           {{ job = [: ]}}
           {{ job.name = item.fullName }}
           {{ job.saved = config.getFile().lastModified()}}
           {{ return job}}
           }

          The above groovy script takes < 5 secs to collect all the job results.

          If the plugin can detect the reload event, it would then just be a matter of comparing timestamps to last saved config-history entry timestamp and save where needed. Should not take long.  If a user goes through the trouble to change a config.xml and reapply the old timestamp, then they meant it to not get detected, so no need to delve deeper.

          To Stefan Brausch, following your "Reload Configuration from Disk", you could simply run the following groovy script from the Jenkins console to save() jobs with the criteria matching that you modified, triggering the plugin to make a new history entry. It is the equivalent of:

          2) ...  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.

          This example matches all jobs in the /admin/ folder. You could iterate over a specific list too.

          Jenkins.instance.allItems.findAll {
           {{it instanceof hudson.model.FreeStyleProject }}
           {{ && it.fullName.matches('(admin)/.*')}}
           {{ }.each { job ->}}
              job.save()
           }
           return
          Show
          ianw Ian Williams added a comment - - edited wrt: "1) ...  It would be a huge task for JobConfigHistory to check the config files of each job", I suppose huge is relative, but we have over 5500 jobs on system. jobInfo = Jenkins.instance.getAllItems(AbstractItem.class).collect { item -> {{ XmlFile config = item.getConfigFile();}} {{ job = [: ]}} {{ job.name = item.fullName }} {{ job.saved = config.getFile().lastModified()}} {{ return job}} } The above groovy script takes < 5 secs to collect all the job results. If the plugin can detect the reload event, it would then just be a matter of comparing timestamps to last saved config-history entry timestamp and save where needed. Should not take long.  If a user goes through the trouble to change a config.xml and reapply the old timestamp, then they meant it to not get detected, so no need to delve deeper. To Stefan Brausch , following your "Reload Configuration from Disk", you could simply run the following groovy script from the Jenkins console to save() jobs with the criteria matching that you modified, triggering the plugin to make a new history entry. It is the equivalent of: 2) ...  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. This example matches all jobs in the /admin/ folder. You could iterate over a specific list too. Jenkins.instance.allItems.findAll { {{it instanceof hudson.model.FreeStyleProject }} {{ && it.fullName.matches( '(admin)/.*' )}} {{ }.each { job ->}}    job.save() } return

            People

            Assignee:
            stefanbrausch Stefan Brausch
            Reporter:
            jelion John Elion
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: