Locking/Unlocking files causing errors for other MRs

Summary

During the Release Post process, we have been locking a features.yml and the unreleased/ directory. This has been a common practice during the release post, but documentation for this practice and its timing cannot be found in GitLab Release Posts handbook page.

After the locks were put in place (Jan 17, 2021), reports of handbook MRs were being being blocked despite not containing changes that touch those files. Discussed in: Slack message in #mr-buddies with thread, Slack message with thread in #release-post, 13.8 Release Post Retrospective

The only workaround seemed to be unlocking this directory data/release_posts/unreleased to allow those other MRs to merge successfully.

Here are several MRs that experienced this bug:

• gitlab-com/www-gitlab-com!70890 (comment 488095148)
• gitlab-com/www-gitlab-com!65797 (comment 488242549)
• gitlab-com/www-gitlab-com!71262 (comment 488239828)
• gitlab-com/www-gitlab-com!71875 (comment 488173564)
• gitlab-com/www-gitlab-com!72150 (comment 488204284)

Steps to reproduce

1. lock a directory such as data/release_posts/unreleased
2. create an MR with changes not associated with this directory
3. attempt to place this MR on the merge train
4. merge train should fail with removed this merge request from the merge train because failed to merge. Something went wrong during merge pre-receive hook. The path 'data/release_posts/unreleased' is locked by USER

Example Project

See MRs above from the handbook project.

What is the current bug behavior?

Unable to merge via the merge train or manually because a unchanged directory is locked.

What is the expected correct behavior?

The merge train or manual merging should succeed.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes