How to use ty in CI
ty can run in CI with no installation step beyond uv. Because ty is a single binary with no runtime dependencies, it adds minimal overhead to your pipeline.
GitHub Actions
The simplest approach uses uvx to run ty without adding it as a project dependency:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v7
- run: uvx ty check src/To get inline annotations on pull requests, use the github output format:
- run: uvx ty check src/ --output-format githubThis produces GitHub-native annotations that appear directly on changed lines in the pull request diff.
GitLab CI
GitLab has a corresponding annotation format:
type-check:
script:
- uvx ty check src/ --output-format gitlabOutput formats
ty supports four output formats, selected with --output-format:
| Format | Use case |
|---|---|
full (default) |
Local development. Multi-line diagnostics with code context. |
concise |
Log parsing and scripting. One line per error. |
github |
GitHub Actions annotations. |
gitlab |
GitLab CI annotations. |
ty check --output-format concisePin ty so a new release can’t break your build
ty ships releases roughly weekly and is still pre-1.0 (0.0.51 as of June 2026). Its diagnostics can change between any two versions, so an unpinned uvx ty check can start failing on a run where none of your code changed.
Pin the version in CI to keep results stable:
- run: uvx ty@0.0.51 check src/When you want a newer release’s checks, bump the pin in its own commit. The diagnostic changes then arrive as a reviewable diff instead of a surprise red build on unrelated work.
If your team can’t absorb periodic pin bumps, a type checker that has already reached 1.0 trades ty’s speed for version stability. See ty vs Pyrefly and when to choose each checker.
Running alongside Ruff
If you already use Ruff in CI, add ty as a separate step:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v7
- run: uvx ruff check .
- run: uvx ruff format --check .
- run: uvx ty check src/