Skip to main content
Actions allow you to create automated workflows that can be run in installs. Actions are useful for debugging, running scripts, and implementing health checks.

​
What are Actions?

Actions are reusable workflows that can be configured to run on your installs. Each action consists of:
  • A trigger that determines when the action runs
  • One or more steps that define what the action does
Actions can be used for:
  • Running database migrations
  • Executing maintenance scripts
  • Collecting diagnostic information
  • Automating operational tasks
  • Running custom health checks

​
How do you configure an Action?

Create an actions directory at the root of the app, and create a .toml file for each action. e.g., alb_healthcheck.toml deployment_restart.toml kubectl_logs.toml. Actions along with components, the sandbox and app metadata are sent to the Nuon control plane with the CLI command nuon apps sync. If you change and add additional actions, you need to run nuon apps sync again to upload the changes. But unlike components, actions do not need to be built. Actions list If actions need to connect to a VCS, use either a public repo (using a public_repo block) or a private GitHub repo (using a connected_repo block). Read more about VCS configuration here. For example, to pull logs from all Kubernetes pods in a namespace, you would write an action like this:
actions/kubectl_logs.toml
#:schema https://api.nuon.co/v1/general/config-schema?type=action
name    = "kubectl_logs"
timeout = "30s"

[[triggers]] type = "manual"

[[steps]] name = "kubectl logs" inline_contents = """ #!/usr/bin/env sh kubectl
logs -n $NAMESPACE --all-containers=true -l app.kubernetes.io/name=ctl-api-api
"""

[steps.env_vars] NAMESPACE = "default"
For example, if you wanted to implement a healthcheck for an AWS ALB, you would write something like this:
actions/http_healthcheck.toml
#: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"
We maintain a collection of commonly-used actions in an open-source repo for you to get started with.

​
Running Actions

Actions can be triggered in several ways:
  • Manually via the Dashboard or CLI
  • On a schedule
  • In response to events
Action workflow To run an action manually with the CLI: 
nuon actions create-run -w <action-workflow-id> -i <install-id>

​
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
Action Triggers are documented in the Changelog 009.

​
Action History

You can view the history of action runs using the Dashboard UI: Action workflows & steps You can view the history of action runs using the CLI: 
nuon actions list-runs -w <action-workflow-id> -i <install-id>
Or get details about a specific run: 
nuon actions get-run -r <run-id> -i <install-id>

​
Action Permissions

Actions are run with the same permissions as the Runner in each install.