By default, the deploy action uses the infer
deploy type, which enables the action to determine whether to use either a dags-only
deploy or an image-and-dags
deploy, depending on the files you change.
Each CI/CD template implementation might have additional requirements.
If you use a self-hosted runner to execute jobs from GitHub Actions, the Astro CLI’s config.yaml
file, which stores default deploy details, might be shared across your organization and hence multiple CI/CD pipelines. To reduce the risk of accidentally deploying to the wrong Deployment, ensure the following:
ASTRO_API_TOKEN
to your repository and include a check in your GitHub workflow to verify that it exists.deployment-id
or deployment-name
in your action. For example, astro deploy <deployment-id>
or astro deploy -n <deployment-name>
.astro logout
at the end of your workflow to ensure that your authentication token is cleared from the config.yaml
file.If you stage multiple commits to dag files and push them all at once to your remote branch, the template only deploys dag code changes from the most recent commit. It will miss any code changes made in previous commits.
To avoid this, either push commits individually or configure your repository to Squash commits for pull requests that merge multiple commits simultaneously.
To automate code deploys to a single Deployment using GitHub Actions, complete the following setup in a Git-based repository that hosts an Astro project:
ASTRO_API_TOKEN
: The value for your Workspace or Organization API token..github/workflows
that includes the following configuration:wake-on-deploy
to your configuration, the Deploy Action wakes a hibernating Deployment before deploying code to it.wake-on-deploy
takes precedence over any existing Deployment hibernation overrides that you configured through the Astro UI or config.yaml
file.