Action inputs and outputs

Modes

One action, seven modes, chosen with the mode input. Leave it out, and the step is auto: it runs the mode the event asks for, and the workflow needs one job.

Mode	What it does	Runs the infrastructure tool
auto	The default. Reads the event of the run and runs what it asks for: scan on a push to the default branch and on the schedule, resolve and then apply for each stack it started and settle on an edit of the dashboard, resolve and scan on a dispatch, check on a pull request. Any other event, an edit of any other issue among them, ends with a notice.	Yes, through scan and apply
scan	Previews stacks and brings the dashboard up to date.	Yes
resolve	Reacts to a tick: checks who ticked, records the deploy and hands the stack to apply.	No
apply	Previews the stack again and deploys it if nothing moved since the tick.	Yes
settle	Gives a deploy a result when its workflow run ended without reporting one.	No
check	Reads the repo’s files and says whether the setup is valid, and which credentials each stack needs, as names, and which of them nothing in the workflow provides (credentials). It needs no credentials, no tool and no GitHub API, so it is safe on any pull request. With backend: true it also asks the backend which stacks it holds, and with pull-request-preview: true it previews the stacks a pull request claims and writes a check run per stack, each with the credentials of its job.	Only with backend: true or pull-request-preview: true
init	Writes a starter workflow and sluiceway.yaml into your clone from what it finds there, and says what is left for you. You run it once on your own machine, as npx sluiceway init, and it commits nothing (init).	No

Inputs

Generated from the action’s action.yml.

mode

What this step does. One of: auto, scan, resolve, apply, settle, check, init. Leave it out for auto, which reads the event of the run and does what it asks for, so one job with this one step runs the whole loop: a push to the default branch and the schedule scan, an edit of the dashboard resolves the ticks, deploys what it started and settles, a dispatch resolves and scans, a pull request runs the check, and any other event ends with a notice. Set another mode for the split workflow, where each mode is a job of its own.

• Required: no
• Default: auto

concurrency

How many previews a scan runs at the same time. Leave it out and the scan runs one preview for each core of the machine, up to 8, and says in the job log which number it used. It belongs to the runner, not to the repo, so it is an input and not a config key.

• Required: no

preview-timeout

Time limit for one preview, in minutes. A preview that runs longer is stopped and its stack gets a preview failure row.

• Required: no
• Default: 10

strict

scan only. true turns the job red when any preview failed, after the dashboard is written. A preview counts as failed after its second try, and a busy stack does not count. Off by default, because a job that is red for one broken stack on every push teaches people to ignore red.

• Required: no
• Default: false

github-token

The GITHUB_TOKEN of the workflow run. Leave it at the default. Sluiceway always acts as the workflow’s own token, and a GitHub App token or a personal access token is not supported. The check mode reads files only and never uses it.

• Required: no
• Default: ${{ github.token }}

deployment-id

Required in apply mode and an error in every other mode. The deployment record to deploy: the deployment field of a matrix entry of resolve.

• Required: no

dry-run

apply only. true rehearses a tick: the deployment record, the fresh preview and the hash check run as for a deploy, and then nothing is deployed. The record ends as inactive, “rehearsed, nothing was deployed”, and the job is green.

• Required: no
• Default: false

backend

check only. true also asks the backend which of the stacks it found the backend holds, with the credentials the job loaded before this step, and gives a ready-to-paste ignore block for the ones it does not. It runs the tool for that one question and nothing else.

• Required: no
• Default: false

pull-request-preview

check and auto only. true also previews the stacks a pull request claims, as they would be after the merge, with the credentials the job loads before this step, and writes a check run per stack on the pull request’s head commit, for the reviewer. Nothing deploys from it, and it leaves no row. A pull request from a fork is refused, and pull_request_target is never used. Off by default.

• Required: no
• Default: false

deploy-timeout

apply only. A time limit on the deploy itself, in whole minutes. When it runs out the tool is interrupted, gets two minutes to stop by itself, and the deploy fails with a reason that says so. The stack may then be half deployed. Empty by default: no limit of Sluiceway’s, and the job’s own timeout-minutes is the limit.

• Required: no

env-file

scan, apply, auto, and check with backend: true or pull-request-preview: true. A file of NAME=value lines, relative to the checkout or absolute, that Sluiceway reads once for the infrastructure tool’s process: every value is masked in the job log before anything else, and the file wins over a variable the job already has. The file may hold plain values or what a step before this one resolved; Sluiceway resolves no secret reference. Empty by default: the tool gets the job environment as it is. On a step that never runs the tool the file is not read. A stacks entry of sluiceway.yaml may name a file of its own with envFile, on top of this one for its stacks.

• Required: no

slack-webhook-url

scan, resolve and apply. The address of a Slack incoming webhook, from a secret of the repo. Sluiceway posts a short message there on the events notify.events in sluiceway.yaml lists. Empty by default: nothing is sent.

• Required: no

telegram-bot-token

scan, resolve and apply. The token of a Telegram bot, from a secret. Needs telegram-chat-id too. Empty by default: nothing is sent.

• Required: no

telegram-chat-id

scan, resolve and apply. The chat the Telegram bot posts to: a chat id or the @ name of a public channel. Empty by default.

• Required: no

telegram-thread-id

scan, resolve and apply. The topic of a forum group the Telegram bot posts to: the topic’s id, a whole number. Needs telegram-bot-token and telegram-chat-id too. Empty by default: the message goes to the chat itself, or to the General topic of a forum group.

• Required: no

webhook-url

scan, resolve and apply. An http or https address, from a secret, that gets a small JSON message on the same events: the event, the repository, the stack ids and the links. Empty by default: nothing is sent.

• Required: no

job-id

Leave it at the default. The id of the running job, which GitHub gives no step in any other way. Links on the dashboard use it to land on this job’s log.

• Required: no
• Default: ${{ job.check_run_id }}

job-status

Leave it at the default. The status of the job before this step. A step that runs with if: !cancelled() runs after an earlier step failed too, and then does none of its work: it puts a line under the scan line of the dashboard that says the run failed before Sluiceway ran, and ends.

• Required: no
• Default: ${{ job.status }}

Outputs

Generated from the action’s action.yml.

matrix

Set by resolve and scan. A JSON list with one { stack, environment, deployment } entry per deploy it started, or []. Hand it to the matrix of the apply job. A scan starts a deploy for a pull request merged from the dashboard (mergeAndDeploy), and the scan of a push to the default branch for each stack set to deploy: on-merge.

dashboard-url

Set by scan, apply and settle. The web address of the dashboard issue. Empty when the step never got as far as finding it.

pending

Set by scan. The number of pending stacks on the dashboard after this scan. 0 when the scan failed before it wrote the dashboard.

preview-failed

Set by scan. The number of stacks on the dashboard whose preview failed. A busy stack is not counted. 0 when the scan failed before it wrote the dashboard.

in-sync

Set by scan. The number of stacks on the dashboard that are in sync. 0 when the scan failed before it wrote the dashboard.

dashboard-changed

Set by scan. true when this scan wrote a body that differs from the one before, false otherwise, so a notify step can stay quiet when nothing changed.

outcome

Set by apply. deployed, in-sync (the fresh preview had nothing to deploy), rehearsed (dry-run stopped after the check of the hash), refused (the change moved since the tick, the deployment record was not one this job may deploy, or deploys are turned off) or failed.

stack

Set by apply. The stack id this job handled. Empty when the job never learned it.

result-file

Set by scan and apply. The path, under RUNNER_TEMP, of a JSON file with what the summary holds: no property value and none of the tool’s own words. Sluiceway does not upload it.