Provider packaging

tinx packages provider packages as OCI image layouts. You can keep the layout on disk, install from it locally, or push it to a registry.

The packaged artifact always contains both the authoring manifest and the normalized package metadata tinx uses at runtime.

tinx pack

Use pack when the bundle sources already exist on disk:

tinx pack \
  --manifest tinx.yaml \
  --artifact-root dist \
  --output oci \
  --tag v1.2.3

pack reads:

• tinx.yaml
• normalized package metadata derived from the manifest
• bundle layer sources for binaries or tarred assets

and writes a directory-based OCI layout to oci/.

tinx release

Use release when tinx should build first and then pack:

tinx release \
  --manifest tinx.yaml \
  --main ./cmd/my-provider \
  --dist dist \
  --output oci

Push to a registry in the same command:

tinx release \
  --manifest tinx.yaml \
  --main ./cmd/my-provider \
  --push ghcr.io/acme/my-provider:v1.2.3

Build strategies

By default, tinx release uses go build for the normalized bundle targets declared in the provider manifest.

If --main is not set, tinx infers a main package from cmd/<binary> for each bundle-backed binary target.

That means a provider package can publish several bundled tools without hard-coding one global entrypoint in the release step.

Use GoReleaser when you already maintain a GoReleaser pipeline:

tinx release \
  --manifest tinx.yaml \
  --delegate-goreleaser \
  --goreleaser-config .goreleaser.yaml

If no GoReleaser config exists, tinx can generate one from the normalized bundle targets in the provider manifest.

What gets packed

Each packaged provider layout contains:

• provider config JSON
• the original tinx.yaml
• normalized package metadata in package.json
• one OCI layer per bundle entry
• tarred asset layers for asset bundles

The provider config records the default tool runtime, entrypoint, and default tool name so tinx can bootstrap installs quickly.

Setup-style providers

Managed-install tools are not built directly unless they also have bundled binaries. Instead, the packaged artifact must include whatever installer tool they depend on.

For example, in setup-kubectl:

• setup-kubectl is bundle-backed and built into the OCI artifact
• kubectl is a local tool whose binary is created lazily by setup-kubectl

Install the result

tinx install acme/my-provider --source ./oci
tinx init demo -p ./oci as my-provider

After install, the workspace shim path handles the final lazy tool materialization on first use.