Skip to main content
Actions allows you to define and remotely execute custom workflows in installs. You can automate common tasks, implement healthchecks, and even automate runbooks to handle incidents.

​
Configuring Action Workflows

Action workflows can be configured in your app’s TOML config. For example, to define an HTTP healthcheck: 
#:schema https://api.nuon.co/v1/general/config-schema?type=action

name = "http_healthcheck" timeout = "0m15s"

[[triggers]] type = "cron" cron_schedule = "_/5 _ \* \* \*"

[[triggers]] type = "manual"

[[steps]] name = "healthcheck" command = "./healthcheck"

[steps.public_repo] repo = "nuonco/actions" branch = "main" directory = "common"

[steps.env_vars] ENDPOINT =
"https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}" METHOD =
"HEAD" EXPECTED_STATUS_CODE = "200"
Once configured and synced, you will see the workflow in the “Actions” tab for your app. Following that example, we can describe the parts of a workflow.

​
Timeout

Each workflow must have a timeout limiting how long it can run. The maxiumum allowed timeout is 30 minutes. Timeouts must be provided as valid Golang time.Duration strings. The example workflow will timeoute after 15 seconds, more than enough time to make a simple HTTP request.

​
Action Triggers

Action triggers are now available for all workflows. You can now use the following set of triggers:
  • pre-provision
  • post-provision
  • pre-reprovision
  • post-reprovision
  • pre-deprovision
  • post-deprovision
  • pre-deploy-all-components
  • post-deploy-all-components
  • pre-teardown-all-components
  • post-teardown-all-components
  • pre-deprovision-sandbox
  • post-deprovision-sandbox
  • pre-reprovision-sandbox
  • post-reprovision-sandbox
  • pre-update-inputs
  • post-update-inputs
  • pre-secrets-sync
  • post-secrets-sync
Each workflow trigger is called at the beginning or end of the workflow. In some cases, such as pre-provision or pre-reprovision that include a stack-run, the trigger will be called right after the runner is healthy. The following triggers require a component_name field to be set, as they are tied to a specific component:
  • pre-deploy-component
  • post-deploy-component
  • post-teardown-component
  • pre-teardown-component
pre-component-deploy and post-component-deploy have been renamed to pre-deploy-component and post-deploy-component for consistency with other triggers. pre-sandbox-run and post-sandbox-run have been deprecated, in favor of pre|post-reprovision, pre|post-provision, and pre|post-deprovision
Actions can be triggered manually, on a cron, or by install events. You can define multiple triggers for an action. The example action defines two triggers. It will run every five minutes, and can also be triggered manually at any time.
actions/<action-name>.toml
[[triggers]]
type          = "cron"
cron_schedule = "*/5 * * * *"

[[triggers]]
type = "manual"

​
Steps

Each step in an action requires a command to be run. You can optionally load a script from a repo and provide env vars to configure the environment the command will run in. The example action is pretty simple, so it has only one step. It loads a curl script from our open-source repo of commonly-used scripts, and sets a few env vars to configure it.
actions/<action-name>.toml
[[steps]]
name    = "healthcheck"
command = "./healthcheck"

[steps.public_repo]
repo      = "nuonco/actions"
branch    = "main"
directory = "common"

[steps.env_vars]
ENDPOINT             = "https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}"
METHOD               = "HEAD"
EXPECTED_STATUS_CODE = "200"

​
Monitoring Workflow Runs

Actions workflow runs can be monitored on the “Actions” tab in each Install. You can see a list of all workflow runs, and inspect each run to see logs, what triggered the run, and whether is succeeded or not.
⌘I