Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.nuon.co/llms.txt

Use this file to discover all available pages before exploring further.

Actions let you define and remotely execute custom workflows in installs. You can automate common tasks, implement healthchecks, and even automate runbooks to handle incidents. For one-off scripts you don’t want to commit to TOML, see Run adhoc actions.

​
Configuring action workflows

Action workflows can be configured in your app’s TOML config. For example, to define an HTTP healthcheck:
actions/http_healthcheck.toml
# 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"
actions/<your-action>.toml
# action
version      = "v1"
description  = "Your app on AWS."
display_name = "Your App"

[[actions]]
source = "./actions/alb_healthcheck.toml"
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 maximum allowed timeout is 30 minutes. Timeouts must be provided as valid Golang time.Duration strings. The example workflow will time out after 15 seconds, more than enough time to make a simple HTTP request.

​
Action triggers

Action triggers are available for all workflows. You can 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
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
# action
[[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
# action
[[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

Action 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 it succeeded or not.