cidx(1) — declarative CI/CD runner

~/projects/my-project
$ go install github.com/cidx-org/cidx/cmd/cidx@latest $ cd my-project && cidx init cidx.toml written (84 lines, 3 phases) $ cidx run ci [security] cargo-audit gitleaks trivy pass 3.2s [code] rustfmt clippy pass 1.1s [test] cargo-test --workspace pass 8.7s [build] cargo-build --release pass 4.3s pipeline ci passed in 17.3s try: help · examples rust · cidx --help · goto github

Name

cidx — declare your CI in one TOML, run it locally, generate the workflow from the same source.

Synopsis

$ cidx init
$ cidx run <pipeline>
$ cidx generate github [-o <path>]

Description

One cidx.toml. One binary. Same containers locally and in CI. You declare what to run — security, code, test, build phases. cidx resolves how: images, commands, volumes, timeouts. Forty-plus presets ship built-in. Generate .github/workflows/cidx.yml from the same source. No daemon, no central service. Drop a cidx.toml in any repo. Remove it the same way.

Examples

Install (requires Go 1.22+):

$ go install github.com/cidx-org/cidx/cmd/cidx@latest

Detect your project and generate the config:

$ cidx init

Run the full pipeline locally — Docker or Podman handles the containers:

$ cidx run ci

Wire it into CI by generating the workflow file once, then committing it:

$ cidx generate github -o .github/workflows/cidx.yml

Docker or Podman must be installed and running — cidx never installs tools on your host, everything runs in containers. Other install methods (release binaries, package managers) in the docs.

Why

Most projects accumulate a tangle of CI YAML, local scripts, and pre-commit hooks that drift out of sync. cidx flips the order: declare the pipeline once in cidx.toml, run it locally with the same containers CI will use, then generate the CI workflow from that same source. If you remove cidx tomorrow, the generated workflow keeps working — it's just YAML.

See Also