Skip to main content

Use tinx in CI

Use tinx in CI when you want providers resolved the same way on developer machines and in automation.

Use an explicit tinx home​

Set --tinx-home or TINX_HOME so the CI cache path is predictable:

export TINX_HOME="$PWD/.tinx-home"
tinx --tinx-home "$TINX_HOME" install ghcr.io/acme/node-provider:v20.19.0

install only pre-populates provider metadata and OCI store content. The first workspace command may still lazily materialize tools.

Materialize from a workspace manifest​

tinx init ci-workspace -p ghcr.io/acme/node-provider:v20.19.0 as node
tinx --workspace ci-workspace -- node --version

Or check in a tinx.yaml and initialize from that manifest:

tinx init ./tinx.yaml
tinx -- node build

Cache the home directory​

Cache these paths between CI jobs:

  • .tinx-home/providers/
  • .tinx-home/store/

That preserves metadata, OCI store content, extracted assets, and previously installed lazy tools so later jobs avoid re-downloading or reinstalling providers.

If you need visibility into what the cache contains, emit inventory in CI logs:

tinx --tinx-home "$TINX_HOME" ls default

Authenticate to registries​

tinx reads registry credentials from standard Docker config and from environment variables such as:

  • TINX_REGISTRY_USERNAME / TINX_REGISTRY_PASSWORD
  • ORAS_USERNAME / ORAS_PASSWORD
  • GITHUB_ACTOR / GITHUB_TOKEN for ghcr.io

Non-interactive execution​

Prefer tinx exec or tinx -- in CI:

tinx exec lite-ci plan
tinx -- node test

Use tinx shell only for local interactive debugging.