# GitLab Triage

GitLab Triage provides a wrapper for the [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) gem, enabling automated triage of issues, merge requests and epics based on a triage policy.

## Settings

The following settings are used to configure the `gitlab-triage` tool:

* `GITLAB_TOKEN` a valid GitLab API token. When running in local development, generate your own [GitLab Personal Access Token](https://docs.gitlab.com/user/profile/personal_access_tokens/).
* `GITLAB_URL` a valid GitLab host URL. For UIS DevOps the host is `https://gitlab.developers.cam.ac.uk/`
* `TRIAGE_SOURCE_ID` the id of the target GitLab `project` or `group`.
* `TRIAGE_SOURCE_TYPE` can be either `projects` or `groups` corresponding to the associated `TRIAGE_SOURCE_ID`.
* `TRIAGE_POLICY_FILE` a YAML file containing a valid triage policy.
* `TRIAGE_DRY_RUN` if set to `true` (or any value other than `false`) dry-run mode is enabled. Defaults to `false`.

## Local Development

We use pre-commit to check linting locally and in the CI pipeline. Before you can run pre-commit hooks locally, you need to have the pre-commit package manager installed:

```sh
pip install pre-commit
```

Following this, install the pre-commit hooks locally by running:

```sh
pre-commit install
```

The local development environment uses the settings loaded from `local-dev-settings.env`. You will need to generate your own [GitLab Personal Access Token](https://docs.gitlab.com/user/profile/personal_access_tokens/) store this new token in your own 1Password vault and update `GITLAB_TOKEN` in `local-dev-settings.env` to the 1Password secret reference pointing to the new token.

We include a working example triage policy `./triage-policies/example-triage-policy.yml` that operates on project `uis/devops/experiments/av603/misc`. When developing you own triage policy, refer to the field names defined in [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) and ensure the policy only affects the intended `TRIAGE_SOURCE_ID` by limiting the project path. For example:

```yaml
ruby:
    "project_path.include?('uis/devops/experiments/av603/misc')"
```

If the `gitlab-triage` gem becomes stale, the version can be refreshed by updating the target version inside the `Gemfile` and regenerating the `Gemfile.lock`. To update the `Gemfile.lock` you can either install the target version of `Ruby` and `bundler` on your local machine and run `bundle install`:

```sh
brew install ruby@3.0
gem install bundler --user-install
bundle install --path vendor/bundle
```

OR by building an image from the `base` target, mount the working directory containing the `Gemfile` inside a container and running `bundle install` from within the container:

```sh
docker build --target base -t gitlab-triage-base:latest .
docker run -it -v "$(pwd):/usr/src/app" -w /usr/src/app gitlab-triage-base:latest /bin/bash
bundle install --path vendor/bundle
bundle update
```