Validate metrics on every pull request

GitHub Action setup

Add a workflow file to your repository at .github/workflows/validate-metrics.yml. The action reads your SQL file, posts it to the MetricRegistry validate endpoint, and fails the PR check if the formula diverges from the canonical definition.

name: Validate Metrics
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: metricregistry/MetricRegistry-UK/action@master
        with:
          api-key: ${{ secrets.METRICREGISTRY_API_KEY }}
          metric-id: uk.banking.capital.cet1_ratio
          sql-file: models/banking/cet1_ratio.sql

Store your API key

The action reads your Pro API key from a GitHub Actions secret — it is never exposed in logs or workflow output.

1. Go to your repo → Settings → Secrets and variables → Actions
2. Click New repository secret and set the name to METRICREGISTRY_API_KEY, with your Pro API key (mrk_...) as the value
3. The action reads it securely via ${{ secrets.METRICREGISTRY_API_KEY }}

Validate multiple metrics

Use a matrix strategy to validate several SQL files in a single job. Each entry runs the action in parallel, so a large model layer validates quickly without sequential bottlenecks.

jobs:
  validate:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        include:
          - metric: uk.banking.capital.cet1_ratio
            file: models/cet1_ratio.sql
          - metric: custom.acmebank.treasury.nim
            file: models/nim.sql
    steps:
      - uses: actions/checkout@v4
      - uses: metricregistry/MetricRegistry-UK/action@master
        with:
          api-key: ${{ secrets.METRICREGISTRY_API_KEY }}
          metric-id: ${{ matrix.metric }}
          sql-file: ${{ matrix.file }}

Custom metrics in CI

Custom metrics work exactly the same way. Use your custom.<workspace>.* metric ID as the metric-id input — the action validates your team's SQL implementations against your own canonical definitions stored in MetricRegistry.

This makes it possible to enforce internal metric standards across multiple teams or data products. Any drift from the agreed formula surfaces as a failed PR check before it reaches your warehouse.

See Custom Metrics to learn how to define your canonical SQL in MetricRegistry.

curl fallback

For GitLab CI, Jenkins, Buildkite, or any other pipeline that can run a shell script, call the validate endpoint directly with curl. Set MR_API_KEY as a CI environment variable or secret. The -fsS flags cause curl to exit non-zero on a 4xx/5xx response, failing the step automatically.

curl -fsS -X POST \
  "https://api.metricregistry.co.uk/metrics/uk.banking.capital.cet1_ratio/validate" \
  -H "Authorization: Bearer $MR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{"sql": "$(cat models/cet1_ratio.sql)"}"

What gets checked

The validate endpoint applies the following checks before comparing your SQL to the canonical definition:

• Normalisation— SQL is normalised for case and whitespace before comparison, so superficial formatting differences do not cause false failures
• Match— your formula is compared against the canonical definition; a match means the computation is equivalent
• Structured advice on mismatch — if validation fails, the response includes actionable guidance, for example: missing NULLIF on denominator — division by zero risk
• PR check failure— the GitHub Action exits non-zero on mismatch, blocking merge until the formula is corrected