Connect Your CI / GitLab CI

GitLab CI — Report Status to UnityFreak

Keep your pipeline exactly as it is. Two extra jobs — one before your test stage, one after — report the outcome to UnityFreak so required checks gate the merge.

TL;DR — The Short Version

Generate a repo:write-scoped token, add it as a masked CI/CD variable named UF_API_KEY, along with UF_OWNER and UF_REPO.
Add a notify-pending job before your tests and two rule-gated result jobs after — notify-success and notify-failure — all three curling the statuses API.
Add the ci/tests context to Required Status Checks in the repository's UnityFreak settings.

1. Generate a Token

Under Settings → Personal Access Tokens, create a token scoped to repo:write — the same scope git push uses, and what authorizes posting a status.

2. Store CI/CD Variables

In the GitLab project's Settings → CI/CD → Variables, add:

UF_API_KEY — masked and protected — the token from step 1.
UF_OWNER and UF_REPO — the owner and repository slug as they appear in your UnityFreak clone URL.

3. The Pipeline

Add these stages around your existing test job in .gitlab-ci.yml:

stages:
  - notify-pending
  - test
  - notify-result

.notify: &notify
  image: curlimages/curl:latest
  script:
    - >
      curl -sf -X POST
      "https://api.unityfreak.com/api/v1/repos/$UF_OWNER/$UF_REPO/statuses/$CI_COMMIT_SHA"
      -H "X-API-Key: $UF_API_KEY"
      -H "Content-Type: application/json"
      -d "{\"state\":\"$STATE\",\"context\":\"ci/tests\",\"targetUrl\":\"$CI_PIPELINE_URL\"}"

notify-pending:
  stage: notify-pending
  variables:
    STATE: pending
  <<: *notify

test:
  stage: test
  script:
    - npm ci
    - npm test

notify-success:
  stage: notify-result
  variables:
    STATE: success
  rules:
    - when: on_success
  <<: *notify

notify-failure:
  stage: notify-result
  variables:
    STATE: failure
  rules:
    - when: on_failure
  <<: *notify

4. Require the Check

In the repository's branch protection settings on UnityFreak, add ci/tests to Required Status Checks. It only appears in that picker after being reported at least once — push through the pipeline above first.

5. Why Two Result Jobs, Not One

It's tempting to write one when: always job that branches on the outcome of the previous stage — but GitLab has no reliable, documented variable exposing an earlier stage's pass/fail result from inside a later job's own script (CI_JOB_STATUS only describes the current job, and only inside after_script). Two separate jobs sidestep the problem entirely: rules: - when: on_success and rules: - when: on_failure let GitLab itself decide which one runs, based on whether the earlier test stage passed — each just posts its own fixed STATE variable, no branching logic needed. The YAML anchor (&notify / <<: *notify) keeps the curl call itself written once.