An implementation if GitHub's CODEOWNERS file, but for GitLab.

The CODEOWNERS file acts exactly as .gitignore. Similary, the file can also be nested in child directories to add/remove inherited users.

* pauldotknopf
*.txt someoneelse

# You can also remove users from previously inherited matches.
*.pdf !pauldotknopf

1. Run the web hook server. Example docker-compose.yml file here. Configurable options here.
   • At a bare minimum, you should have the following configured for Bulwark to properly communicate with GitLab.

   {
     "GitLab": {
       "AuthenticationToken": "your-auth-token"
      }
   }
   

   This configuration should go in a config.json file in the working directory of the running Bulwark instance.
2. On GitLab under Project > Settings > Integrations, add a web hook that points to https://your-bulwark-instance.com/gitlab and tick the following:
   • Push events
   • Merge request events
3. On GitLab under Project > Settings > General, tick following:
   • Merge request approvals
   • Can override approvers and approvals required per merge request
   • Remove all approvals in a merge request when new commits are pushed to its source branch (optional)

That's it. Submit a pull request with a CODEOWNERS file and watch users get automatically assigned as reviewers.

Defaults:

{
  "MessageQueue": {
    "Type": "Sqlite",
    "SqlLiteDBLocation": "sqlite.db",
    "RabbitMqHost": null,
    "RabbitMqUsername": null,
    "RabbitMqPassword": null,
    "RabbitMqPort": 5672
  }
}

Details:

• "Type":
  • "Sqlite" - The default method. New messages are stored in the database and a worker thread (or another process) consumes them.
  • "RabbitMq" - Use an external RabbitMQ server to store the message.

Defaults:

{
  "GitLab": {
    "Enabled": true,
    "ServerUrl": "https://gitlab.com/",
    "AuthenticationToken": null,
    "SecretToken": null,
    "TargetBranchesFilter": null,
    "AutoMergePullRequests": false,
    "MergeCommitMessage": null,
    "MergeWhenPipelineSuceeds": null,
    "ShouldRemoveSourceBranch": null,
    "UseHttp": true,
    "HttpUsername: null,
    "HttpPassword": null
  }
}

Details:

• "ServerUrl": You can point this to gitlab.com or your own hosted GitLab instance.
• "AuthenticationToken": Generate this from your account settings.
• "SecretToken": The secret token, configured in GitLab, for the web hook. This ensures that only GitLab can post to your hook.
• "TargetBranchesFilter": A regular expression to match against branches you wish to process. You may want to set this to "master".
• "AutoMergePullRequests": If all the required approvers have approved, you can configure Bulwark to auto merge the merge request. You might want to update your Project > Settings > Repository > Protected Branches settings to only authorize Bulwark to merge your merge requests to your desired branch.
• "MergeCommitMessage": Self explanatory, empty if you want GitLab to auto-generate a merge commit message. You can alse use tokens {MergeRequestTitle} and {MergeRequestReference} for a message like {MergeRequestTitle}\nSee {MergeRequestReference} for more detais..
• "MergeWhenPipelineSuceeds": When performing the merge, only do so when pipelines succeed.
• "ShouldRemoveSourceBranch": Self explanatory, empty if you want to let GitLab to use the configured value for the merge request.
• "UseHttp": Use http to clone git repositories. Otherwise, ssh.
• "HttpUsername": The username to use when cloning via http.
• "HttpPassword": The password to use when cloding via http.

Defaults:

{
  "RepositoryCache": {
    "RepositoryCacheLocation": "repository-cache"
  }
}

Details:

• "RepositoryCacheLocation": The directory that repositories will be cloned to do internal diffs between commits.