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

Form validation on orphaned item strategies immediately deleting unmatched repos (was: Changing Jenkinsfile filename resets build number to 1…)

    Details

    • Similar Issues:

      Description

      What happend:
      I recently changed on project with 27 build runs the project settings from "Jenkinsfile" to "Jenkinsfile.groovy". A "Scan Multibranch Pipeline" happend and could not find that file, because git repo was not prepared for that change (a commit/push would have caused a build run before i where able to change the project settings). Build history disappeared. Removing "Jenkinsfile" and adding "Jenkinsfile.groovy" with the next commit enables "Scan Multibranch Pipeline" to find the "Jenkinsfile.groovy" but build number was reset to 1 and history of the other 27 builds is still gone.

      BTW: I am not sure why the filename refactoring in IntelliJ IDEA did not end up in a git tracked file rename (as deleted and created instead), but this is not be the root cause here (i think), because the multibranch feature is a VCS agnostic feature (as far as i know; should work with other VCS than git, so should not tied to git rename tracking).

      Expected behaviour:

      When changing the Jenkinsfile filename the build history should stay intact and the very next available build number should be picket for next build. Resetting build number to 1 is not desireable. If it is not possible to keep the old build history and build number than a "Do you really want to drop build history and reset your build number?" should be asked when changing Jenkinsfile filename in project settings. Build numbers are very important to track changes from ticket to release and for support feedback loop. Disrupting the tracking chain and integration with other tools (ticket system, artifact repo, documentation, etc.) is a very bad impact.

      Please provide instruction:
       - on how to recover to old history (Jenkinsfile)
       - on how to go ahead with Jenkins.groovy, keeping old history and maintaining build numbers (next = 28)

      I am running:
      Jenkins: Jenkins ver. 2.46.2
      Pipeline Multibranch (workflow-multibranch-plugin) 2.16

      Changing the filename was introduced by https://issues.jenkins-ci.org/browse/JENKINS-34561 i think that case was not tested. JENKINS-34561 was merged at 2017-06-05 and release on 2017-06-20 (see https://github.com/jenkinsci/workflow-multibranch-plugin/releases )

      I think the one in https://issues.jenkins-ci.org/browse/JENKINS-36244 could ran into the same problem (but he or she could not figure out the root cause) - i link his/her ticket here as related.

        Attachments

          Activity

          Hide
          stephenconnolly Stephen Connolly added a comment -

          If you have configured the Orphaned Item strategy to not retain any branches, and you remove the Jenkinsfile then that is no longer a branch and should be deleted.

          If you want to keep the build history through transient issues then an Orphaned Item strategy that retains items for some period of time should be configured.

          Functioning as designed (though I agree that the documentation may not be clear enough on how these things are expected to interact)

          Show
          stephenconnolly Stephen Connolly added a comment - If you have configured the Orphaned Item strategy to not retain any branches, and you remove the Jenkinsfile then that is no longer a branch and should be deleted. If you want to keep the build history through transient issues then an Orphaned Item strategy that retains items for some period of time should be configured. Functioning as designed (though I agree that the documentation may not be clear enough on how these things are expected to interact)
          Hide
          stephenconnolly Stephen Connolly added a comment -

          Please provide instruction: 
           - on how to recover to old history (Jenkinsfile)
           - on how to go ahead with Jenkins.groovy, keeping old history and maintaining build numbers (next = 28)

          There is no way to recover the old history after the job has been deleted by the Orphaned Item Strategy unless you have a backup.

          I recommend going forward that you configure the Orphaned Item strategy to retain items for a period of time if you are likely to be repeating refactorings of this nature.

          Show
          stephenconnolly Stephen Connolly added a comment - Please provide instruction:   - on how to recover to old history (Jenkinsfile)  - on how to go ahead with Jenkins.groovy, keeping old history and maintaining build numbers (next = 28) There is no way to recover the old history after the job has been deleted by the Orphaned Item Strategy unless you have a backup. I recommend going forward that you configure the Orphaned Item strategy to retain items for a period of time if you are likely to be repeating refactorings of this nature.
          Hide
          christian_weiss_simplicity Christian Weiss added a comment -

          Even if each feature works as defined the user experience (UX) can be broken.
          I re-open this ticket as as UX-BUG. As because data gets lost its prio remains at critical.

          At least the user should be asked to confirm before saving that project setting change, when "Orphanded Item Strategy" is set to "Discard old items" with a "Days to keep old items" = 0 (default values). And when "Days to keep old items" is set > 0 then a warning should be presented to guide the user to do the naming transition on all branches within that count of days, to not loose build history.

          I would recommend to increase default for "Days to keep old items" to 1.

          Show
          christian_weiss_simplicity Christian Weiss added a comment - Even if each feature works as defined the user experience (UX) can be broken. I re-open this ticket as as UX-BUG. As because data gets lost its prio remains at critical. At least the user should be asked to confirm before saving that project setting change, when "Orphanded Item Strategy" is set to "Discard old items" with a "Days to keep old items" = 0 (default values). And when "Days to keep old items" is set > 0 then a warning should be presented to guide the user to do the naming transition on all branches within that count of days, to not loose build history. I would recommend to increase default for "Days to keep old items" to 1.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          The orphaned item strategy does not allow a value of 0 any more

          Show
          stephenconnolly Stephen Connolly added a comment - The orphaned item strategy does not allow a value of 0 any more

            People

            • Assignee:
              Unassigned
              Reporter:
              christian_weiss_simplicity Christian Weiss
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: