# CI

```sh
waitcher ci init [--env production] [--file waitcher.json] [--output PATH] [--branch NAME]
```

Writes a GitHub Actions workflow (default `.github/workflows/waitcher.yml`) that runs `waitcher deploy plan` on pull requests and `waitcher deploy apply` on pushes to the branch (default: the repository's default branch) for one environment, never two runs at once. Run it from the repository root; run it again with another `--env` and `--output` for a second environment. The workflow installs the CLI from waitcher.dev, checks the archive's SHA-256, runs `npm ci` when there is a `package-lock.json`, and signs in with the `WAITCHER_TOKEN` repository secret.

Set up the token once, from a signed-in session:

1. Deploy once so the project exists, and note its `project.id`.
2. Create a project token ([Access](access.md#project-reach)) with `read` and `write`, plus `run` if you add `--smoke` to the apply step:

   ```json
   { "name": "GitHub Actions", "scopes": ["read", "write"], "projectId": "PROJECT_ID" }
   ```

   ```sh
   waitcher token create --file token.json --output ./private/github-token.json
   gh secret set WAITCHER_TOKEN < ./private/github-token.json
   ```

3. Commit the workflow.

The workflow never runs `auth logout`, which would revoke the token. CI applies without `--based-on`, so the latest file on the branch wins; new monitors still start paused unless you add `--activate-new`. Rotate the token before it expires with `waitcher token rotate` and update the secret.