Allow deletion of protected branches

Resources

FE @samrose3 | UX @pedroms

Description

Allow masters, owners & admins to delete protected branches.

Proposal

In the Branches page

• Add a Delete tooltip to the all of the Delete buttons
• For Master users (which also includes Owners and Admins), enable the Delete buttons for protected branches
• When pressing the Delete button for a protected branch, show the following confirmation modal:
  • 
  • Note that the branch name in the confirmation input label should be enclosed in <kbd> and not <code>

# Delete protected branch ‘feature/new-awesome-feature’?

You’re about to permanently delete the protected branch **feature/new-awesome-feature**.

This branch hasn’t been merged yet. To avoid data loss, consider merging this branch into another before deleting it.

Once you confirm and press **Delete protected branch**, it cannot be undone or recovered.

To confirm, type <kbd>feature/new-awesome-feature</kbd>

Cancel | Delete protected branch

• For non-Master users (Guests, Reporters or Developers), to give them some info on why the Delete button is disabled for them, add a tooltip to that button: Only a project master or owner can delete a protected branch

In Git

Deleting a protected branch is only allowed via the web interface, not via Git. This means that people can't accidentally delete protected branches.

In Git, return the following message when attempting to delete a protected branch:

• For masters/owners/admins: To delete a protected branch, use the web interface.
• For non-master users (guests/reporters/developers): Only a project master or owner can delete a protected branch.

Links / references

http://docs.gitlab.com/ee/user/project/protected_branches.html

Documentation blurb

Deleting a protected branch

From time to time, it may be required to delete or clean up branches that are protected. In older versions of GitLab, this was only possible by removing the protection, deleting the branch and then manually re-enabling it. Not only was this cumbersome, but also allowed pushing to branches that should have been protected during this manual process.

Owners and admins can now manually delete protected branches by visiting the Repository Branches and clicking on the delete icon. In order to prevent accidental deletion of protected branches, an additional confirmation is required.

---

Original Issue

With the past releases for GitLab the capability of protecting several branches by wildcard has been introduced.

http://docs.gitlab.com/ee/user/project/protected_branches.html

Unfortunately, even for a master user, there is no way to delete a branch that is protected under wildcard even if the branch is not longer needed, forcing the removal of the wildcard for the removal of the branch. This opens to possible issues with the other branches that are protected under that wildcard.

Example:

wildcard: release-v-* branches protected:

• release-v-1.0.0
• release-v-1.0.1
• release-v-1.1.0

To remove the branch release-v-1.0.0 you are now required to remove the wildcard release-v-* which will automatically make the other 2 release branches unprotected.

Request:

Add the functionality of unprotecting a protected branch by wildcard as long as the user is a master or administrator level user (not developer role). So the clean up of past protected branches can be done.

Added feature proposal repository labels

@markglenfletcher I would almost call this a bug because it creates a pretty significant usage gap; but it will require some sort of UI change to alter the gap, so I could see why it is labeled as a "feature proposal".

Just the same, it's worth highlighting just how impactful this gap is:

The wildcard feature allows you to protect routinely created branches with minimal effort. This implies several branches will be protected over time and it is natural that some of these branches will become meaningless over time and it is natural to want to prune your project to avoid distracting clutter. However, once one of these previously "important" branches becomes obsolete, you can't delete it -- it's protected!

To work around this, you either have to (a) unprotect all branches that follow the pattern for a period of time, putting them at risk, while you delete the one branch which is obsolete; (b) forego the wildcard feature entirely; (c) you never delete any branch that was ever protected by a wildcard; (d) you schedule downtime to delete obsolete branches where general access is blocked.

Option (a) risks data loss. Option (b) renders wildcard protections unusable. Option (c) encourages a unnecessarily messy project. Option (d) is just ridiculous.

Most users will end up with workaround option (a) and just accept the "window of risk" while they delete the branch. Some will argue that it is a relatively small window, but it grows as the number of contributors and/or number of still-meaningful branches covered by the wildcard. Any way you slice it, the value of protected branch features are undermined (a, b) or you have to make notable tradeoffs (c, d).

@crussell52 Thank you for the detailed feedback.

@crussell52 and @mcloide1977 If it's OK, it would be good to understand your own usage of protected branches, to gather some more context for this issue and to understand the different ways that the wildcard feature is being used in the field.

For the branches that are protected in the GitLab-CE project, we never intend to delete them. They'll be everpresent for posterity. All other branches are feature branches that can be deleted.

@markglenfletcher My org uses a variant of git-flow, so I'll use that as a basis instead of bogging your down with the details of our workflow specifics... I think that will illustrate the use case.

I'm sure you are familiar, but for the sake of detail: http://nvie.com/posts/a-successful-git-branching-model/

So there's a part in git flow where you create your release branch. That branch follows a pattern, but only lives until your code goes to production. (In my org's variation, it lives longer than that but I don't think that detail matters too much.) During its life, developers are contributing to the release branch (release candidate fixes) and simultaneously moving on with new development in the main development branch. So even it it takes a full sprint to get the release out the door for whatever odd reason, development is never blocked and the release candidate never becomes polluted with new development.

The important part here is that our release branches are as sacred as our development branches and are subject to the same policies -- no history rewriting, merge pending review only -- the perfect candidate for protected branches! Without wildcard support we have to always go through the ceremony of creating the branch, protecting the branch, and setting permissions on the branch (love that feature, btw). Wildcard support makes it fantastic because we don't need to do any of that... until of course, we want to delete the branch because we are no maintaining it.

So I guess the fact that the release branch lives a bit longer than traditional git-flow does matter a bit here... because we produce patch versions from that branch for the life of the major/minor version so we tend to have two active release during each major/minor release cycle -- the one we are using for maintenance of the current major/minor version and the one we are using for release candidate of the next major/minor version. That's what makes it undesirable to remove the protection just to delete one of the two branches. We even have some edge cases where we have more than two release branches. Not often, but it can happen.

@JobV Please could you take a look at this issue regarding the deletion of branches protected with a wildcard?

@crussell52 by your own analysis, finding a medium between ease of deletion and maintaining the protection is not easy. What do you suggest?

I don't think we should undermine protected branches by having admin or masters able to delete them without removing the protection.

I think the easiest solution is to make it quick to protect and unprotect single branches and not make use of wildcards when working with branches you want to get rid of often.

We could, for instance, add a button when you've pushed a new branch to immediately protect it.

@JobV I agree that the balance is hard to strike... Perhaps the goal should be to make protected branches harder, but not impossible to delete?

For example, deleting a project requires the master/owner to re-type the name of the project in a very explicit warning box prior to deleting. Deleting a protected branch is certainly no less risky than deleting an entire project, so perhaps following that pattern would allow the operation while mitigating the risk of accidental deletion? Perhaps the delete button can have a different look to it for the protected branches as well.

Of course, such a mechanic would extend outside of wildcard protections and apply to all protected branches. That would save steps for anybody who is trying to delete a protected branch (currently, you have to navigate several screens to unprotect then delete the branch).

@crussell52 I'm still not convinced. It sounds like we're undermining the meaning of 'protected'. In addition, right now they are protected on git level, meaning that we can't easily override this in GitLab without lifting the protection from outside of GitLab as well.

I'll leave this open for further feedback.

@JobV I'm not clear on why the ability to delete a protected branch, with added confirmation, undermines the meaning of protected.

The meaning of 'protected' branches to be guarded against force pushes, unauthorized pushes, and deletion; this is very important for the duration of the branch's useful life.

The cost of keeping (now) useless branches around is added clutter/distraction in drop-downs, lists, and command line output. What is the value of keeping an obsolete branch around?

And I think this is at the heart of this request. It's really a request to be able to delete obsolete, protected branches.

We currently are suffering from the same problem. We want to prevent junior developers from pushing and merging to feature branches and thus force them to use merge requests. Using the wildcards easily lets master and owner create feature branches that are automatically protected through the wildcard, but there is no way to delete a finished and merged feature branch without lifting the whole wildcard. Stating that is managed at git level is not an valid argument since that is managed by gitlab itself through hooks. If you can manage push control at git level, you can managed deletion control as well. Lots of people use the popular git flow in favor of gitlab flow, making this a valid request. I just wish I could vote up multiple times, emphesising the importance of this issue for our company.

We are also suffering this in our EE instance. We follow Git-flow and our release/* and hotfix/* are protected to prevent direct pushed to them. After a release we want to delete these branches as they are no longer needed but don't want to unprotect all other branches matching the wildcard. Maybe allowing the branch deletion only from Gitlab itself (not by pushing the deletion) and only after the branch has been merged somewhere to ensure no changes will be lost with the deletion.

@JobV I might be able to help. At this moment, whenever I need to delete a protected branch that is protected by wildcard I need to 1st remove the wildcard and then remove the branch. Consider time into the situation.

• 1 - remove wildcard
• 2 - remove branch
• 3 - add wildcard

If, for some reason, a developer that is not supposed to push to a protected branch, such as an intern, pushes to that branch it will automatically have pushed some risk which now has to be reverted. Now consider this same scenario if you do have more than one branch under the wildcard (the whole idea of the wildcard).

If you consider that, in the best case scenario, takes 1 minute between 1 and 3, a lot can happen on that minute because, as we know, git takes a matter of seconds to push to a branch.

So having the ability of removing a protected branch by wildcard when it becomes obsolete without removing to the wildcard is not a matter of maintenance is more of a matter of security.

Maybe it can have a 2 step process where you can setup a branch, protected by wildcard, as obsolete and that makes it available for deletion.

We have the same use case as bravecobra. We have official branches than only configuration managers can push to. We do not really care if the configuration managers (masters) delete the branches. We just need to lock the branches down so that developers cannot modify/delete them. Since we use a wildcard to lock down the branches we cannot clean up the obsolete branches.

Added ~480950 label

@markglenfletcher Any update on this?

Our instance of GitLab EE is getting quite cluttered. The only current "safe" option is to remove the wildcard after hours when nobody should be using GitLab... then recreate the protection.... then reconfigure the permissions for the wildcard. Very inefficient.

Also not really a safe operation since it unprotects several branches that are still important.

@mydigitalself Please could you take a look?

added shortlist label

In the same way that setting up protected branches has Allowed to merge and Allowed to push we could potentially add an Allowed to delete. That way if people do want to set this up as an optional policy, they are welcome to do so and it wouldn't impact those who want a stricter enforcement.

The UI of the list of protected branches may need some tweaking as the width of the table wouldn't support this right now.

@JobV wdyt?

added ~19492 label

@pedroms - Can you help out with this issue? Thanks!

changed milestone to %9.0

added frontend label

added Stretch label

mentioned in issue #27894 (closed)

After talking with @mydigitalself, I propose:

• In the Branches page, for Master users (which also includes Owners and Admins), enable the Delete buttons for protected branches
• When pressing the Delete button for a protected branch, show the following confirmation modal:

The Delete merged branches button should not delete protected branches, even if they've been merged.

Additionally, in the same page, for non-Master users (Guests, Reporters or Developers), to give them some info on why the Delete button is disabled, show the following tooltip when hovering that button:

Outstanding!

@pedroms That sounds like a workable solution for us as well. Perfect! Let's get it done ;)

removed shortlist label

changed milestone to %9.1

@pedroms What should we do when a master, owner or admin attempts to delete a branch using git itself (git push origin :branch-to-delete)? Show an error saying they can only delete it through the web interface, perhaps?

Right now it says:

You are not allowed to delete protected branches from this project.

We could show masters/owners/admins:

You are not allowed to delete this protected branch using Git. Please do so using the web interface.

And others:

You are not allowed to delete this protected branch. Please ask a project master or owner.

@pedroms As for the tooltip on the disabled delete button, I suggest "Only a project master or owner can delete a protected branch."

• I don't think we need to explicitly call out admins, since that's a role that transcends all access control, and is always assumed to be able to do anything. Within the context of the project, only master and owner are roles that matter.
• I think phrasing it as a rule is clearer than a suggestion to ask someone else.

assigned to @pedroms

removed Stretch label

changed milestone to %9.2

@pedroms It looks like this was moved to 9.2. It would still be good to get the UX flushed out when you have some time after 9.1 issues

mentioned in issue #22638 (closed)

added ~897282 label

added Deliverable label

Reassigning FE for this to @samrose3

@pedroms @tauriedavis what is the status on the UX for this? I'm ready to start implementing ~Frontend stuff when you are 👍

It looks almost flushed out. @pedroms Can you take a look - there are some comments about copy above but and then we can move it to UX ready for @samrose3

changed title from Delete a protected past branch by wildcard. to Allow deletion of protected branches

assigned to @samrose3

@samrose3 I've updated the description with some changes, picking up on @DouweM suggestions. Let me know if you have any questions.

mentioned in issue #28849 (moved)

created branch 21393-allow-deletion-of-protected-branches

mentioned in merge request !11000 (merged)

closed via merge request !11000 (merged)

added docs-todo label

@axil Description contains docs instructions.

mentioned in issue #32218 (closed)

@mydigitalself thanks, I created https://gitlab.com/gitlab-org/gitlab-ce/issues/32218 to track the docs. We need an open issue in order to appear in the issue board :)

mentioned in issue #32295 (closed)

Did this make it into 9.2? I'm not seeing the option to delete protected branches on gitlab.com now that it's running 9.2RC3

@HRMsimon Thanks for looking into this. It doesn't appear so, the Merge Request was merged after the feature freeze on the 7th of the month.

@iamphill Should the milestone for this feature be changed to %9.3?

Yeah it missed the feature freeze by a day. So will be in 9.3

changed milestone to %9.3

mentioned in merge request gitlab-com/www-gitlab-com!5551 (merged)

mentioned in issue #34553 (closed)