How it works

A scan previews your stacks, and nothing deploys until someone ticks a box, unless your own sluiceway.yaml sets a stack to go out on merge.

1. After a merge to the default branch, and once a day, a scan previews the stacks in the repo.
2. The scan writes the dashboard issue: one row per stack, and a box on every stack that has changes waiting.
3. You tick a box. That asks for that stack to be deployed exactly as its row shows it.
4. Sluiceway checks that you may tick that stack, and previews it again. It deploys only if the fresh preview still matches the row.
5. The row goes back to in sync, or says why the deploy failed, with a link to the run.

The issue is a view and never the source of truth. What is pending is always worked out again from a fresh preview.

What it promises

• Your credentials stay in your runners, and there is no backend. Previews and deploys run in your own runners with the secrets your workflow loads, or with the env file you name, which Sluiceway reads for the tool and masks. Sluiceway itself fetches no credential, and calls the GitHub API and nothing else (security).
• A fresh preview before every deploy. A tick deploys only what the row showed. If the change moved since, nothing is deployed and the row comes back with the new diff (what a tick promises).
• No values, unless you list them. Rows show resource types, resource names and the paths of changed properties, never a value, except at the paths you list, and never one the tool marks secret (what reaches the issue).

What it does

• Pulumi, with stacks found from their files alone (configuration).
• OpenTofu and Terraform, with root modules found from their files when the files say so: a backend block, a lock file or .tofu files that name the tool, and no other directory using the directory as a module. Anything else, and Terragrunt or CDK for Terraform, is declared in sluiceway.yaml. A tick deploys the plan file whose diff the row showed (configuration, stacks[].tool).
• Helm, with a release in a namespace declared in sluiceway.yaml. A tick deploys only what the chart rendered when the diff was checked (stacks[].tool).
• Kubernetes manifests, with a directory of manifests or a kustomization declared in sluiceway.yaml. A tick deploys the set of manifests that was diffed (stacks[].tool).
• Tick to deploy. One box per stack with changes waiting, checked against who may tick (using the dashboard).
• Deploy on merge, per stack, opt-in: a stack you set to deploy: on-merge goes out after the merge that changed it, through the same fresh preview as a tick, attributed to whoever merged. A delete, a replace or drift still waits for a tick, and every other stack keeps its box (configuration).
• Policies, opt-in: Rego policies that Conftest runs against the preview of every pending stack, in the same job. A policy that fails takes the box off the row, names the policy in its own words, and stops a deploy on merge (configuration).
• Merge and deploy, for Renovate and other routine updates: one tick merges a green pull request and deploys its stack (merge and deploy).
• Drift, opt-in: a scheduled scan finds changes made outside the code, and a tick puts them back (drift.enabled).
• Stack dependencies with dependsOn or phases: a stack waits for the stacks it depends on, or for every stack of the phases before its own, and a chain deploys one layer per run (dependsOn, phases).
• A preview page per pending stack, a check run with the stack’s whole diff (using the dashboard).
• The check mode, which reads your files in a pull request and says what Sluiceway will find and what your workflow lacks (check your setup).
• A pull request preview, opt-in: the check previews the stacks a pull request claims, as they would be after the merge, and writes a check run per stack for the reviewer. Nothing deploys from it, and a fork is refused (check your setup).
• Values at the paths you list with showValues, such as a chart’s version, and the tool’s own diff in the job log if you ask (dashboard.showValues). Every other value is covered by a fingerprint on the row, so a value that changed since the tick stops the deploy without being shown (what a tick promises).
• Stop every deploy, or rehearse a tick: deploys: false stops every deploy, and dry-run rehearses a tick without deploying (deploys, dry-run).
• Notifications, opt-in: a short message to Slack, Telegram or your own webhook when stacks are pending, drift is found, a deploy fails or a tick is refused, plus outputs and a result file for anything else (notifications).
• Readable by scripts and agents: the markers in the dashboard, the payload of each deployment record and the result file are documented and versioned, with a JSON schema for the payload and the result file, and a rule for what may change (what Sluiceway hands over).