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

JobConfigHistory plugin retention policy fails to preserve latest changes

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • Windows 7 x64
      Jenkins LTS v1.532.3
      JobConfigHistory Plugin v2.6

      We have the JobConfigHistory plugin installed and configured to dispose of historic changes older than 30 days. Recently we noticed that when a job does not undergo changes for an extended period of time, the plugin will delete all historic changes except the very first change when the job was initially created.

      This is quite different than the logic found in, say, the build log retention policy provided by Jenkins natively. By comparison, when using a similar set of options, this logic will delete all historic logs except the latest one.

      The behavior of the latter seems much more intuitive and useful.

      Example Use Case
      Suppose you create a new job, and spend the next week or so making adjustments to the configuration to correct bugs and such with the job. Now suppose you don't touch the job for 6 months, after which you find yourself needed to make a change to the job configuration. Further, after making this change you discover that your changes do not work and you want to revert back to the previous state. To do so you open the jobs configuration history only to discover that there are only 2 historic states available to choose from: the one tracking the change you just made, and the one from the original creation of the job. So basically now there is no way for you to revert your changes to the state that existed just prior to your most recent change.

      Recommendation
      When deleting obsolete job configurations from the history, it would be much more beneficial to preserve the most recent change from the history and delete all prior changes than it would be to delete the most recent changes and preserve the original one when the job was initially created.

          [JENKINS-22884] JobConfigHistory plugin retention policy fails to preserve latest changes

          In my opinion, the current behavior makes the time-sensitive historic preservation option completely useless. In our case it is particularly problematic since we've been using Jenkins for over a year now, and many of our 700+ jobs were created months ago so there is now no way for us to preserve the current state of our jobs in the event any configuration changes are required.

          The only workaround we can think of at the moment is to disable the time-limited history preservation and opt to use the static number of historic changes instead. This is less than ideal because we don't necessarily want to cache dozens of changes across hundreds of jobs indefinitely, but we most definitely do want to preserve the most recent change to those jobs indefinitely.

          Kevin Phillips added a comment - In my opinion, the current behavior makes the time-sensitive historic preservation option completely useless. In our case it is particularly problematic since we've been using Jenkins for over a year now, and many of our 700+ jobs were created months ago so there is now no way for us to preserve the current state of our jobs in the event any configuration changes are required. The only workaround we can think of at the moment is to disable the time-limited history preservation and opt to use the static number of historic changes instead. This is less than ideal because we don't necessarily want to cache dozens of changes across hundreds of jobs indefinitely, but we most definitely do want to preserve the most recent change to those jobs indefinitely.

            mfriedenhagen Mirko Friedenhagen
            leedega Kevin Phillips
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: