Skip to content
Integrations

CI integration

CI health workflow generation is unavailable. Inspect the refusal and optionally collect a separate local source-drift report.

The shape

In the reviewed source, CI health workflow generation is unavailable:

  1. Review the Phantom Cloud boundary: unattended pull is unsupported by Phantom Secrets 0.7.9.
  2. Inspect stack ci init. The admitted source refuses workflow generation with exit code 1; it does not write a workflow.
  3. Optionally collect a JSON source-drift report separately. It is not a credentialed health check or working CI bootstrap.

Unattended Cloud pull is unsupported with Phantom Secrets 0.7.9. Cloud pull requires stdin, stdout and stderr on a trusted terminal; --force only declares overwrites and does not bypass that requirement. PHANTOM_CLOUD_TOKEN is not a supported Cloud bearer-token input, and the local vault passphrase is not the separate Cloud encryption key. Adding those GitHub secrets does not enable unattended Cloud pull.

Check workflow availability

# Inspect the installed command interface
stack ci init --help

# Reviewed source refuses generation with exit 1
stack ci init

# Compatibility flag: still refuses; does not overwrite
stack ci init --force
# Bare `stack ci` gives the same refusal; --json prints {"error": "..."}
stack ci --json

The source first checks whether .stack.toml exists; this is not TOML validation. If .github/workflows/stack-ci.yml already exists and --force is absent, it reports that the file was not changed. Otherwise it reports generation unavailable. All these command-body refusal paths exit 1 before any workflow directory creation or file write. --force only changes which refusal is reached; it is not an overwrite override.

Refusal output

CI health workflow unavailable: Phantom Cloud pull requires trusted-terminal approval. No workflow was written. Instead, run `stack doctor` from a trusted terminal, or `stack doctor --reconcile --json` in CI for a credential-free source-drift report.

Cloud prerequisites

These names appeared in the former Cloud recipe. Adding them in Settings → Secrets and variables → Actions does not enable unattended Cloud pull with Phantom Secrets 0.7.9:

Secret Where it comes from
PHANTOM_VAULT_PASSPHRASE A local-vault passphrase is not Phantom Secrets 0.7.9’s separate Cloud encryption key. It does not enable unattended Cloud pull.
PHANTOM_CLOUD_TOKEN Phantom Secrets 0.7.9 reads its Cloud bearer token from its credential store, not this environment variable. Check phantom --help; this environment variable is not supported Cloud authentication.

Exit-code behaviour

# Illustrative source refusal; no workflow write
$ stack ci init
CI health workflow unavailable: Phantom Cloud pull requires trusted-terminal approval. No workflow was written. Instead, run `stack doctor` from a trusted terminal, or `stack doctor --reconcile --json` in CI for a credential-free source-drift report.
$ echo $?
1

The existing config and file guards also refuse with exit 1. Running a GitHub job manually does not supply the trusted-terminal ceremony required by Phantom Secrets 0.7.9. The producer does not emit a Cloud workflow, and no unattended health integration is established here.

Optional source-drift report

{
  "configured": ["supabase"],
  "detected": [],
  "orphans": ["supabase"],
  "untracked": []
}

The JSON above illustrates stack doctor --reconcile --json: configured and detected record config services and source detections; orphans and untracked record their differences. This branch returns before Phantom and health checks and returns 0 on detected drift. Tooling must inspect the fields; scanner or I/O errors can still fail. It is not credential or provider-health acceptance.

Other CI systems

stack ci init does not generate a health workflow for GitHub Actions or another CI system. An optional source-drift report can be collected separately:

# Optional local source-drift report; drift itself returns 0
stack doctor --reconcile --json > stack-source-drift.json

A supported unattended credentialed health integration remains separate work. Open an issue on GitHub if you want yours prioritised.

stack scan in CI — existing repos

If you're adopting Stack in a repo that already has services wired up manually (environment variables set, packages installed), use stack scan to detect them without interactive prompts:

# Report detected services without adding them
stack scan --json --confidence medium
Flag Behaviour
--json Emit a machine-readable JSON report and exit 0. No prompts, and nothing is added even with --yes. Suitable for parsing in downstream steps.
--yes Without --json, implies --auto and enables add attempts at or above the confidence tier without confirmation. With --json, scan reports hits and returns before adding services. Without either flag, a non-TTY run prints the read-only report; --auto without --yes exits 1.
--confidence <low|medium|high> Filter by the named tier. The default is medium, or high with --yes; the example explicitly selects medium.

Illustrative JSON output shape:

{
  "hits": [
    { "provider": "resend", "confidence": "high", "sources": ["package.json:resend"] },
    { "provider": "supabase", "confidence": "high", "sources": ["package.json:@supabase/supabase-js"] }
  ]
}

Combine with stack doctor --reconcile to also detect drift between .stack.toml and source imports. See Maintenance for details.

Rotating secrets from CI

Rotate at the provider using its supported process. Stack doctor reports available checks; it does not rotate credentials. stack login <provider> runs the provider login path, but cached credentials and create-only storage can prevent replacement. Verify the resulting slot and your separately qualified CI credential delivery before relying on it.