CI

GitHub Action

Re-check your app every time a migration lands on your default branch. The action starts a PatchLabs check, waits for the lab result, prints it in the job summary, and fails the build if strangers can read personal data.

Set up in three steps

1. Add and verify the app

   Sign in, add the repo as an app and commit its verification file. See monitoring. Copy the app’s ID from its page.

2. Create an API key

   In Settings → API keys, create a key named, say, “GitHub Actions”. It’s shown once. In your repo, open Settings → Secrets and variables → Actions and add it as the secret PATCHLABS_API_KEY. Add the app ID as the variable PATCHLABS_APP_ID.

3. Add the workflow

   Save this as .github/workflows/patchlabs.yml:

   .github/workflows/patchlabs.ymlCopy

   name: PatchLabs
   on:
     push:
       branches: [main]
       paths: ['supabase/migrations/**']
     workflow_dispatch:
   
   concurrency: patchlabs
   
   jobs:
     leak-check:
       runs-on: ubuntu-latest
       steps:
         - uses: manra399/patchlabs/action@main
           with:
             api-key: ${{ secrets.PATCHLABS_API_KEY }}
             app-id: ${{ vars.PATCHLABS_APP_ID }}
             wait: true
             fail-on-leak: true

No checkout step is needed: PatchLabs reads the repo from GitHub. concurrency stops two runs from overlapping, since an app can only have one check open at a time.

What you see

PatchLabs check started: 7c1e2f0a-…
Status: queued
Status: running
 
PatchLabs · you/shop-app
  result         Leaks found; a lab-proven
                  fix is ready
  tables leaking  profiles
  lab proof       passed
  report          https://patchlabs.dev/check?id=…
 
Error: Leaks found … Apply the fix, then re-run.

The same result goes into the job summary as a small table with a link to the report. After you apply the fix, re-run the job: it passes once the check reads no_leaks.

Inputs

Outputs

Use them in later steps, for example to post the report link somewhere:

      - id: patchlabs
        uses: manra399/patchlabs/action@main
        with:
          api-key: ${{ secrets.PATCHLABS_API_KEY }}
          app-id: ${{ vars.PATCHLABS_APP_ID }}
          fail-on-leak: false
      - if: steps.patchlabs.outputs.leaks-found == 'true'
        run: echo "Leaking tables: ${{ steps.patchlabs.outputs.tables-leaking }} → ${{ steps.patchlabs.outputs.url }}"

How each result is handled

On a schedule

Monitoring already re-checks your app weekly or monthly. If you’d rather see results in GitHub, add a cron trigger:

on:
  schedule:
    - cron: '0 6 * * 1'   # Mondays at 06:00 UTC
  workflow_dispatch:

How it works

The action is a small shell script that uses curl and jq (both preinstalled on GitHub-hosted Linux and macOS runners). It calls two endpoints with your key:

1. POST /v1/apps/{app_id}/checks to start a check;
2. GET /v1/checks/{id} every poll-seconds until finished is true.

The source is in the action/ folder of the manra399/patchlabs repo. Read it before you use it; it’s about 130 lines. For a fixed version, pin a commit SHA instead of @main.

Good to know