Veri Product Workflow Docs GitHub Download

The CI gate

On one machine, veri check is a habit. On a team, it has to be a gate: the Veri Check GitHub Action runs the same checker on every pull request, so a change that breaks the knowledge base can't merge quietly.

The action wraps Veri's own CLI — the identical check derivation your terminal runs — so a local veri check and the PR verdict can never disagree. It runs entirely inside your CI: no hosted service, no credentials, nothing leaves the runner.

1. Add the workflow

One file in your repo, .github/workflows/veri-check.yml:

name: Veri gate

on:
  pull_request:
  push:
    branches: [main]

jobs:
  veri-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: danielyayla/veri@v1

That's the whole setup. fetch-depth: 0 matters: receipt verification checks the commits your receipts cite against real history, and a shallow checkout doesn't have it. On a shallow checkout the action doesn't guess — it skips receipt verification and says so in an annotation rather than reporting false findings.

2. What fails, what warns

The action keeps the CLI's two tiers exactly:

To make advisories block too:

      - uses: danielyayla/veri@v1
        with:
          strict-advisories: true

3. Inputs and outputs

InputDefaultMeaning
path.Project root — the directory containing veri/ — relative to the workspace, for monorepos where the knowledge base isn't at the top.
strict-advisoriesfalseFail the run when advisories are present instead of only annotating.

The step exposes issues and advisories counts as outputs, and writes a short verdict table to the job summary.

Veri eats its own gate

The Veri repository runs this exact action on its own pull requests — the knowledge base that builds Veri is protected by the check Veri ships. If the gate were ever wrong, it would break our own merges first.