Tronador CLI v0.2: Safer Project and IaC Workflows from the Terminal

Created: August 6, 2026 Updated: August 6, 2026

Cloud Ops Works has released tronador-cli v0.2.3, the latest patch in the v0.2 line. This release turns more of the repository and infrastructure lifecycle into explicit, inspectable command-line workflows: project operations no longer need to dispatch through a Makefile, IaC module upgrades respect the requested release tier, and real tool output remains visible while automation keeps reliable exit status and JSON behavior.

One naming detail is worth making explicit before looking at the commands: the repository and package-manager package are still called tronador-cli, while the binary installed by release artifacts is tronador. For example, install it with brew install cloudopsworks/tap/tronador-cli, then run tronador version.

What changed across v0.2

The v0.2 release line is cumulative. v0.2.0 introduced the larger project and IaC workflow surface; v0.2.1 and v0.2.2 refined how version tiers are reported and selected; and v0.2.3 makes project-backed tools stream their output without weakening automation behavior.

Project capabilities without Makefile dispatch

The new tronador project command detects the implementation through a regular marker file under .cloudopsworks/ and presents only the operations that implementation supports. That replaces guesswork with a discoverable contract:

tronador project detect
tronador project capabilities

The detector supports Cloud Ops Works application markers for Android, Docker, .NET, Flutter, Go, Java, Node, Python, Rust, and Xcode, as well as Terraform modules and Terragrunt projects. It only inspects the requested work directory, so a command aimed at one repository does not accidentally infer another checkout's configuration.

Once capabilities are listed, run the relevant native pipeline:

tronador project init
tronador project lint
tronador project format
tronador project version

Mutation-capable commands support --dry-run, allowing a team to review the ordered tool calls before changing a repository. The commands use typed arguments rather than invoking shell bootstrap scripts or Makefile targets, which makes the plan easier to inspect and reduces the chance of quoting or dispatch surprises. Destructive Terragrunt cleanup remains explicit: tronador project clean --yes.

For automation, both detection and capability discovery support --workdir and stable --json output:

tronador project detect --workdir ../service --json
tronador project capabilities --workdir ../service --json

IaC module upgrades that match the requested scope

tronador iac module scans direct GitHub module sources pinned with ?ref= in terragrunt.hcl. In report mode it calculates the highest eligible patch, minor, and major targets independently. In upgrade mode, the selected tier controls what may be rewritten:

# Report available release tiers without modifying files.
tronador iac module --workdir ../my-iac-workspace

# Preview normal patch-line upgrades.
tronador iac module --workdir ../my-iac-workspace --upgrade --dry-run

# Select a broader compatible tier deliberately.
tronador iac module --workdir ../my-iac-workspace --upgrade --minor
tronador iac module --workdir ../my-iac-workspace --upgrade --major

The follow-up v0.2 updates make the result more useful in real repositories. The report now prints only concrete, available release tiers. When --major finds no later major release, v0.2.2 falls back to the highest eligible later minor release in the current major line instead of selecting an unrelated target or failing silently. If neither target exists, the pinned reference remains unchanged.

Stable semantic-version tags are eligible by default. Teams that intentionally track prereleases can opt in to numeric alpha and beta tags:

tronador iac module --workdir ../my-iac-workspace --upgrade --alpha --beta

The command remains conservative about scope. It requires the .cloudopsworks/.iac workspace marker, rejects discovery paths outside --workdir, reports unsupported sources rather than guessing, and does not rewrite sources without an explicit ?ref= pin. It can also normalize a missing git:: prefix without changing version pins:

tronador iac module --workdir ../my-iac-workspace --fix-prefix

Tool output that is visible and still automatable

Infrastructure tools often produce the diagnostic information that explains a failed plan, formatting issue, or provider error. Before v0.2.3, a wrapper that captured child-process output could make that feedback less immediate. The latest patch streams child tool output to the terminal while preserving the capture and exit-status behavior the CLI needs to correctly decide success or failure.

That design matters for both humans and CI:

• an operator sees tool progress and diagnostics as they happen;
• a calling workflow retains reliable exit status;
• machine-readable command paths keep JSON output clean instead of mixing it with tool chatter; and
• regression coverage exercises real child processes rather than only mocked results.

The result is not a new command to memorize. It is a better execution contract for the existing project workflows: direct feedback for people, predictable signals for automation.

Repository upgrades continue to preserve local ownership

The v0.2 repository lifecycle work keeps the public make repos/* workflow available through tronador repos. The normal upgrade path detects the template type, selects the latest compatible tag in the current major/minor line, applies the template stack, updates CI/CD metadata, and commits the template change:

tronador repos available --workdir ../service
tronador repos upgrade --workdir ../service

The release also keeps implementation-owned files safe during template upgrades. Existing issue and pull-request templates, Dependabot configuration, and auto-assignment configuration are preserved. Template-owned .gitignore content is merged through explicit BEGIN TRONADOR TEMPLATE MANAGED BLOCK and END TRONADOR TEMPLATE MANAGED BLOCK markers, leaving user-managed content outside the block intact.

Install and verify v0.2.3

Install through the method that fits the platform:

# Linux or macOS
curl -fsSL https://raw.githubusercontent.com/cloudopsworks/tronador-cli/master/scripts/install.sh | sh

# Homebrew
brew install cloudopsworks/tap/tronador-cli

# Windows PowerShell
# iwr https://raw.githubusercontent.com/cloudopsworks/tronador-cli/master/scripts/install.ps1 -UseB | iex

Then verify the released executable and inspect the available commands:

tronador version
tronador --help
tronador project capabilities --workdir .

For package-specific installation, upgrades, Linux packages, and uninstall steps, read the Tronador CLI installation guide. The source, release assets, and full command documentation are available in the cloudopsworks/tronador-cli repository.