Skip to docs content
Input & Integration/CI Setup

Input & Integration

CI Setup

The GitHub Action, version pinning, and how acknowledgements flow.

Two-line adoption

layoutd ships a GitHub Action that wraps layoutd check. Add it to a workflow, point it at your two IDL versions, and every pull request that touches an account layout is gated automatically.

.github/workflows/layoutd.yml
name: layoutdon: [pull_request] jobs:  layout-check:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: layoutd/check-action@v0.1.0   # pin the version        with:          v1: idl/userstate.v1.json          v2: idl/userstate.v2.json          account: UserState          ack: .layoutd-ack.toml             # optional acknowledgements

Pin the version

Always pin an exact action version (@v0.1.0, not a floating tag). A verdict must never change silently between runs — pinning guarantees the classifier that passed your last PR is the same one gating the next.

Version pinning is mandatory

An unpinned action could change its classification rules under you, turning a previously-safe upgrade into a silent failure — or worse, a silent pass. Pin it.

PR annotations

The Action consumes check’s SARIF 2.1.0 output, and GitHub renders each finding as an inline annotation on the changed lines. Reviewers see the field, the verdict, and the reason directly in the pull request.

How acknowledgements flow

  • A DANGER verdict fails the check and blocks the merge by default.
  • To accept a deliberate danger, add it to the ack file named in the workflow (e.g. .layoutd-ack.toml).
  • Only the named change passes; any other danger still fails. The acknowledgement is committed alongside the change, so it’s reviewable and permanent.

For the rules behind the verdicts, see The Risk Model.