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

Differential backups should not cause Jenkins to stop running new jobs

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • thinbackup-plugin
    • None

      How to reproduce:
      1. Set a thinBackup schedule.
      2. Create a periodic (or SCM-triggered) job which runs for a long time.
      3. Create other jobs which run quickly.

      What happens:
      1. The slow job starts.
      2. thinBackup triggers, and sets Jenkins to "quiet down" mode, not allowing any more jobs to start.
      3. Any triggered or scheduled fast jobs now have to wait for the slow job and the backup to finish before continuing.
      4. While thinBackup is waiting for the jobs to finish, "Jenkins is going to shut down" is prominently shown on every page.

      As this waiting time could be very long, this can mean a large amount of time wasted because of idling machines and waiting developers. The warning message is also misleading enough to make this a major issue.

      To be able to run frequent backups without losing time, it would be nice if thinBackup could simply not set Jenkins to "quiet down" mode, and instead back up only builds which are finished. If this is done in a similar fashion to rsync (copying only files which are newer than the target) there shouldn't even be any problems with jobs modifying older builds (for example as part of post-build tasks).

      Workaround: Set the schedule to back up only when people aren't using Jenkins.

          [JENKINS-20837] Differential backups should not cause Jenkins to stop running new jobs

          Thomas Fürer added a comment -

          thank you for your realy detailed description. i will take care about when I implement thin-backup 2.0.

          Thomas Fürer added a comment - thank you for your realy detailed description. i will take care about when I implement thin-backup 2.0.

          I also run into the same problem for the same scenarios described in this ticket.
          And I like the proposed solution, as long as only the running builds, and not the whole job where at least one build is currently running, are skipped. In other words, I would want to make sure that my job configuration in particular, is backed up regardless.
          I believe this is what the description is indeed saying but I wanted to be explicit about that.

          Patrice Matignon added a comment - I also run into the same problem for the same scenarios described in this ticket. And I like the proposed solution, as long as only the running builds, and not the whole job where at least one build is currently running, are skipped. In other words, I would want to make sure that my job configuration in particular, is backed up regardless. I believe this is what the description is indeed saying but I wanted to be explicit about that.

            tofuatjava Thomas Fürer
            l0b0 Victor Engmark
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: