{"id":49507,"date":"2025-05-28T01:24:59","date_gmt":"2025-05-28T01:24:59","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=49507"},"modified":"2025-05-28T01:24:59","modified_gmt":"2025-05-28T01:24:59","slug":"gitlab-codeowners-file-enforce-code-reviews-approvals-and-accountability","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/gitlab-codeowners-file-enforce-code-reviews-approvals-and-accountability\/","title":{"rendered":"GitLab CODEOWNERS file – enforce code reviews, approvals, and accountability"},"content":{"rendered":"\n

The CODEOWNERS<\/code> file in GitLab<\/strong> is a special file that lets you define who is responsible (owner)<\/strong> for specific files, directories, or patterns in your repository. It\u2019s a powerful feature to enforce code reviews<\/strong>, approvals<\/strong>, and accountability<\/strong>\u2014especially for sensitive or critical parts of your codebase.<\/p>\n\n\n\n

\n\n\n\n

\u2705 What Does the CODEOWNERS<\/code> File Do?<\/h3>\n\n\n\n

When a file or directory covered by a CODEOWNERS<\/code> rule is modified in a merge request<\/strong>:<\/p>\n\n\n\n

    \n
  1. GitLab automatically requests approval<\/strong> from the listed owners.<\/li>\n\n\n\n
  2. If you enforce approval rules<\/strong>, the MR cannot be merged<\/strong> without their review (when configured).<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    \ud83d\udcc4 Syntax of CODEOWNERS<\/code><\/h3>\n\n\n\n

    Each line defines a path pattern<\/strong> followed by one or more GitLab usernames or groups<\/strong>.<\/p>\n\n\n

    # Syntax: <file pattern> <usernames or groups><\/span>\n\/README.md         @john\n\/docs\/             @tech-writers\n\/secrets\/*         @security<\/span>-team @admin<\/span>\n*.yml              @devops<\/span>\n<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
    \n\n\n\n
    \ud83d\udcc1 Where to Place CODEOWNERS<\/code><\/h3>\n\n\n\n
    GitLab looks for the file in one of these locations (in order of priority):<\/p>\n\n\n\n
      \n
    1. .gitlab\/CODEOWNERS<\/code><\/li>\n\n\n\n
    2. docs\/CODEOWNERS<\/code><\/li>\n\n\n\n
    3. CODEOWNERS<\/code> (root)<\/li>\n<\/ol>\n\n\n\n
      \ud83d\udc49 Best practice: place it in .gitlab\/CODEOWNERS<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      \ud83d\udd10 How CODEOWNERS Works with Approval Rules<\/h3>\n\n\n\n
      To enforce the rules:<\/p>\n\n\n\n
        \n
      1. Go to Project \u2192 Settings \u2192 General \u2192 Merge request approvals<\/strong><\/li>\n\n\n\n
      2. Enable: \u201cRequire approval from Code Owners\u201d<\/strong><\/li>\n\n\n\n
      3. GitLab will now enforce at least one approval from any listed owner<\/strong> if their path is touched.<\/li>\n<\/ol>\n\n\n\n
        \n\n\n\n
        \ud83e\udde0 Example Use Case<\/h3>\n\n\n
        # Enforce ownership on critical configs<\/span>\n\/config\/production.yml @devops-lead\n\n# Only security team can approve secrets file<\/span>\n\/secrets\/* @security<\/span>-team\n<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
        When someone opens an MR touching \/config\/production.yml<\/code>, GitLab:<\/p>\n\n\n\n
          \n
        • Requests approval from @devops-lead<\/code><\/li>\n\n\n\n
        • Blocks merging if approval is required and not yet given<\/li>\n<\/ul>\n\n\n\n
          \n\n\n\n
          \ud83d\udd0d Pro Tips<\/h3>\n\n\n\n
            \n
          • You can use groups like @my-org\/security<\/code> as owners.<\/li>\n\n\n\n
          • Owners must have at least Developer<\/strong> access to the repo.<\/li>\n\n\n\n
          • Use together with merge request approval rules<\/strong> for full control.<\/li>\n<\/ul>\n\n\n\n
            \n\n\n\n
            <\/p>\n","protected":false},"excerpt":{"rendered":"
            The CODEOWNERS file in GitLab is a special file that lets you define who is responsible (owner) for specific files, directories, or patterns in your repository. It\u2019s a powerful feature… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-49507","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49507","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=49507"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49507\/revisions"}],"predecessor-version":[{"id":49508,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/49507\/revisions\/49508"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=49507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=49507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=49507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}