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

Cleanup of deleted branches and closed PRs does not happen automatically

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins LTS 2.319.1
      GitHub Branch Source 2.11.4

      When a multibranch pipeline job, the deleted branches and closed PRs get striked-out but they do no get removed automatically. This results in disk space being consumed for those obsolete branches and PRs. Orphaned Stategy is set as 'Discard old items' checked, with no values in 'Days to keep old items' or 'Max # of old items to keep'.

      However, when I manually trigger "Scan Repository Now", all striked-out branches and PRs get removed.

      Why are those branches/PRs not getting deleted instead of just being striked out ? How can the cleanup be handled automatically ?

          [JENKINS-68259] Cleanup of deleted branches and closed PRs does not happen automatically

          This would be valuable for non-GitHub branch sources as well. Implementation strategies were discussed in JENKINS-60677, which was however resolved without this feature.

          Kalle Niemitalo added a comment - This would be valuable for non-GitHub branch sources as well. Implementation strategies were discussed in JENKINS-60677 , which was however resolved without this feature.

          If this were implemented in the Branch API plugin rather than the GitHub Branch Source plugin, so that it would apply to Bitbucket Branch Source too, then there would be a complication with the Bitbucket Server 7.7 feature that automatically declines inactive pull requests. Bitbucket Server does not post any warning to the pull request before automatically declining it. Pull requests sometimes remain inactive for several weeks even though they are still needed. When Bitbucket Server automatically declines such a pull request, we reopen it right away. It would be unfortunate if the automatic decline immediately caused Jenkins to discard the build history and reset the build number.

          Perhaps Jenkins should distinguish between merged, declined, and deleted pull requests. If a pull request is merged or deleted, then it cannot be reopened (although a new pull request can be created from the same branch), and it's OK to delete the corresponding job from Jenkins immediately. If a pull request is declined, then it can still be reopened, and the corresponding job should be preserved for a few days.

          Or perhaps I should ask Atlassian to make Bitbucket Server post a comment to each pull request that is about to be automatically declined.

          Kalle Niemitalo added a comment - If this were implemented in the Branch API plugin rather than the GitHub Branch Source plugin, so that it would apply to Bitbucket Branch Source too, then there would be a complication with the Bitbucket Server 7.7 feature that automatically declines inactive pull requests . Bitbucket Server does not post any warning to the pull request before automatically declining it. Pull requests sometimes remain inactive for several weeks even though they are still needed. When Bitbucket Server automatically declines such a pull request, we reopen it right away. It would be unfortunate if the automatic decline immediately caused Jenkins to discard the build history and reset the build number. Perhaps Jenkins should distinguish between merged , declined , and deleted pull requests. If a pull request is merged or deleted, then it cannot be reopened (although a new pull request can be created from the same branch), and it's OK to delete the corresponding job from Jenkins immediately. If a pull request is declined, then it can still be reopened, and the corresponding job should be preserved for a few days. Or perhaps I should ask Atlassian to make Bitbucket Server post a comment to each pull request that is about to be automatically declined.

          Jean-Luc Pé added a comment -

          Hi all,

          Could it be possible to have a status about this problem. It is indeed quite annoying to have to manually cleanup workspaces.

          Best Regards

          Jean-Luc Pé added a comment - Hi all, Could it be possible to have a status about this problem. It is indeed quite annoying to have to manually cleanup workspaces. Best Regards

          I think Jenkins could be changed to automatically delete workspaces even while the branch job still exists in the multibranch project, if it has disabled the job because the branch no longer exists in SCM. So it would still keep the runs (including logs, test results, and artifacts). Perhaps that feature could fit in the existing Distributed Workspace Clean plugin.

          Kalle Niemitalo added a comment - I think Jenkins could be changed to automatically delete workspaces even while the branch job still exists in the multibranch project, if it has disabled the job because the branch no longer exists in SCM. So it would still keep the runs (including logs, test results, and artifacts). Perhaps that feature could fit in the existing Distributed Workspace Clean plugin .

            Unassigned Unassigned
            richmond Rich
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: