CI workflow

Continuous integration should exercise Asagiri without prompting, ideally in dry-run mode where that matches your intent, and without ever echoing secrets into job logs.

Recommended pattern

A typical lane builds the CLI, initializes project metadata, runs doctor, and performs a work dry-run plus plan-only pass so pipelines stay fast and deterministic. Adapt paths and caching to your platform; the excerpt below sketches the ordering:

# excerpt — adapt to your CI
- run: go build -o bin/asa ./application/cmd/asa
- run: bin/asa init
  working-directory: ${{ github.workspace }}
- run: bin/asa doctor
- run: bin/asa work "smoke feature" --dry-run --plan-only
- run: go test -race ./...

Environment variables

When you prefer flags-as-env rather than repeating CLI switches, Asagiri honours the usual mirrors:

See Environment variables.

Docs CI

This repository also validates that the published docs remain buildable and that CLI reference generation stays in sync with code. The sequence below mirrors what runs on push:

cd docs-site && npm ci && npm run build
go run ./application/cmd/asa docs generate-cli --output docs-site/content/docs/en/cli/generated
go test ./application/internal/cli/docgen/...

Workflow file: .github/workflows/docs.yml.

What not to do in CI

Treat CI as rehearsal and hygiene, not unattended production automation unless you have deliberately pinned agents, secrets scopes, and review gates.

• Do not run real dev/review without pinned agents and secrets
• Do not commit .asagiri/config.yaml with tokens
• Do not treat --estimate-only as a license skip for go test

Related

• Contributing
• Security
• CLI: verify