# CI

The yotoshelf/ci catalog components, what each gate checks, and the Renovate preset.

## Pipeline structure

YotoShelf uses a GitLab CI pipeline with components from the [yotoshelf/ci](https://gitlab.com/yotoshelf/ci) catalog. The pipeline runs on every push to a merge request branch and on every push to `main`.

## Gates

| Job | What it checks |
|---|---|
| `lint` | golangci-lint (Go), ESLint (frontend) |
| `test` | `go test ./...` (unit tests) |
| `build` | `go build` + `npm run build` |
| `sqlc` | sqlc vet — queries match the schema |
| `file-size` | No file exceeds 500 lines |
| `i18n` | No hard-coded user-facing strings in Svelte |
| `e2e` | Playwright end-to-end against a seeded database |
| `container` | Container image builds successfully |

All gates must pass before a MR can be merged. There is no manual override.

## Renovate

Dependency updates are automated via Renovate. The `renovate.json` at the repository root extends the `yotoshelf/ci` preset, which:

- Groups patch-level updates into a single weekly MR
- Separates major version bumps for human review
- Auto-merges patch updates that pass all gates
- Excludes `go-yoto` from auto-merge (API-adjacent, always human-reviewed)

## Smoke tests

A weekly scheduled pipeline runs the go-yoto integration tests against the real Yoto API to detect upstream drift. See [go-yoto Client](/reference/go-yoto) for details.