### Problem to solve GitLab's File Locking feature should lock a particular file for all branches, not just the default branch. GitLab's File Locking Feature currently only prevents merges into the Default Branch (typically `master` although can be changed Settings > Repository > Default Branch). This is misleading as it allows users to modify locked files in any other branch. This is a problem when there are particular repository files that need to be protected from users with developer access. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> A benefit of this is to protect developers from modifying the `.gitlab-ci.yml` and/or any files executed or referenced the `.gitlab-ci.yml`. Suppose I have a `.gitlab-ci.yml` that utilizes Maven to run `pom.xml` file. I could potentially rewrite the `pom.xml` file to expose a GitLab CI Variable containing a secret to an external service. As of [12.6](https://gitlab.com/gitlab-org/gitlab/issues/14376), I can prevent users from modifying the `.gitlab-ci.yml` file, but it does not prevent users from modifying files used by the `.gitlab-ci.yml` file. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Per @fjsanpedro, it should be possible to lock all files regardless of whether or the change is applied to the default branch due to updates to the API. The code ignoring all non-default branches is in the [git_access.rb](https://gitlab.com/gitlab-org/gitlab/blob/22ff44212983e7ba6b954b78de261ec3a403d38e/lib/gitlab/git_access.rb#L203-225) file. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> The proposed change is in line with how the [File Locking](https://docs.gitlab.com/ee/user/project/file_lock.html) documentation is written as there is no indication that it only protects the default branch. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> No documentation should need to be changed - although we could explicitly declare that file locks will lock the file across all branches. https://docs.gitlab.com/ee/user/project/file_lock.html ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> This change ought to be tested both in making commits via the Git CLI as well as the Web IDE to ensure that proper errors are returned. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> We ought to no longer be able to push or merge to any branches where a file is locked by any user that is not the owner of the file lock. ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> Given that File Lock is a Premium feature, this would remain a Premium feature. ### Links / references