Recommended next

Purpose

Use ota-run/setup@v1 when a GitHub Actions job needs ota on PATH for later direct commands such as ota run setup, ota run ci, or ota run deploy:cloudflare.

This action is the installer/bootstrap boundary for GitHub Actions. It does not render readiness summaries, annotations, or pull-request comments.

install ota through the official installer
add ota to PATH for later steps in the same job
fail closed with install: never when the runner is already provisioned
keep installer behavior separate from GitHub-native reporting

Use when

a later workflow step must invoke ota directly
you want to replace hand-written install snippets such as curl ... install.sh | sh
a release or deploy job needs ota but does not need the reporting wrapper itself
the workflow should keep installer behavior explicit and reusable

Quick start

Workflowyaml

steps:  - uses: actions/checkout@v5   - name: Setup ota    uses: ota-run/setup@v1    with:      ota-version: 1.5.0   - name: Validate contract    run: ota validate   - name: Verify    run: |      ota run setup --stream      ota run ci

Inputs

install controls installation behavior and supports always or never; default: always.
ota-version pins the installer to a specific ota release such as v1.5.0 when reproducibility matters.
ota-bin overrides the ota binary name or path after installation resolution; path-like values are resolved from the workflow working directory; default: ota.

Outputs

ota-bin returns the resolved ota binary path selected by the action.
ota-version returns the resolved ota version reported by that binary.
installed reports whether the action performed installation during the current run.

Install behavior

install: always forces installer use before selecting the binary.
install: never requires ota to already exist and fails closed otherwise.
self-hosted runners should provide pwsh on Windows or sh plus curl on Unix-like runners when installer mode is used.
missing installer prerequisites now fail with an explicit operator message instead of a generic install error.

Job boundary

the action adds ota to PATH for later steps in the same job
that does not carry into a different job
if another job also needs direct ota commands, run ota-run/setup@v1 there too

Relationship to ota-run/action

use ota-run/action@v1 for readiness summaries, annotations, pull-request comments, and receipt artifacts
use ota-run/setup@v1 when you need ota installed for later direct commands
use both together when a workflow needs a read-only readiness gate first and direct ota commands later

Source repo

The setup action source, release tags, and workflow examples live in GitHub.

The official GitHub Action for installing ota. Put ota on PATH for later workflow steps without hand-written install scripts.

Open on GitHub