Skip to main content
The Astro GitHub integration can automatically deploy code from a GitHub repository to Astro without you needing to configure a GitHub action. In addition, the Astro UI shows Git metadata for each deploy on your Deployment information screen. See Deploy code with the Astro GitHub integration for setup steps.
GitHub Action templates use the Astronomer-maintained deploy-action, which is available in the GitHub Marketplace. This action automates the deploy process and includes additional features for more complex automation workflows. Specifically, the action can automatically:
  • Choose a deploy type based on the files that were changed in a commit. This allows you to use the same template for dag deploys and image deploys.
  • Test dags as part of the deploy process and prevent deploying if any of the tests fail. These tests are defined in the tests directory of your Astro project.
  • Create a preview Deployment to test your code before deploying to production. A Deployment preview is an Astro Deployment that mirrors the configuration of an existing Deployment.
  • Allows you to choose the type of code deploys used by the automation:
    • (Default) infer
    • image-and-dags
    • image-only
    • dags-only
    • dbt
    • non-dags
If you have one Deployment and one environment on Astro, use the single branch implementation. If you have multiple Deployments that support development and production environments, use the multiple branch implementation. If your team builds custom Docker images, use the custom image implementation. If you don’t have access to Astronomer’s deploy-action, use the private network templates. To learn more about CI/CD on Astro, see Choose a CI/CD strategy.
If you use GitHub Enterprise and cannot access the Astronomer Deploy Action, see Private network templates.

​
Deploy type

The deploy-action includes several deploy types for you to choose a specific type of code deploy for your CI/CD processes.
See the Deploy Action README to learn more about using and customizing this action, like creating a GitHub action that can support dag and dbt deploys.

​
(Default) infer

By default, the deploy-action uses infer, which allows it to determine the type of code deploy to use based on the types of files changed in a commit: Dag or Astro project. If you committed changes only to dag files, the action triggers a dag deploy. If you committed changes to any other file, the action triggers an image deploy, or image-and-dags. This setting does not include dbt deploy types. See default deploy action.

​
image-and-dags

The image-and-dags option enables the Deploy Action to make a full project deploy, which includes both images and dags. This option will also include code in includes/, plugins/, or any other directories in the root of the repository. For example, if you have a dbt project in a dbt/ directory, it will be included when using this Deploy Action.

​
image-only

The image-only option enables the Deploy Action to deploy only the Docker image of your Astro project without updating existing dags on your Deployment. Use this option when you want to push dependency or configuration changes independently of your dag code. This deploy type skips dag parsing and pytest validation. Requires Astro CLI version 1.21.0 or later.

​
dags-only

The dags-only deploy option enables the deploy action to deploy only the dags in your Astro project’s dags directory to your Deployment. To deploy Dags from a different folder or to a named Dag bundle, see Deploy to named Dag bundles. The action skips the deploy when no changed files are in the dags folder, or in dags-path when you set it. Starting with deploy-action 0.17.0, if the action can’t determine the changed files and Dag deploys are enabled on the Deployment, it deploys the Dags. This happens for a manual workflow dispatch, a push that creates a branch, or a missing diff base. Earlier versions deploy nothing in these cases.

​
dbt

The dbt deploy option enables the Deploy Action to deploy dbt projects to Astro, when you provide the path to a directory in your GitHub repo that contains your dbt project. See dbt deploy action. This is most commonly used when your dbt code/logic does not live in the same repository as your Astro project.

​
non-dags

The non-dags deploy option deploys any folder as a non-Dag bundle, such as SQL files or configuration files that your Dags read at runtime. Requires deploy-action 0.17.0 or later and Astro CLI 1.44.0 or later.
  • root-folder is required. It’s the folder that the action deploys as the bundle.
  • mount-path is required. It’s the absolute path where the bundle mounts in Airflow, and the path your Dags use to read its files.
  • non-dags-bundle-type is optional. It’s a free-form label that appears in the Deploy History tab.
The bundle folder can’t be inside an Astro project. For example, astro-project/ and sql/ side by side in your repository works, but astro-project/sql/ fails. You can’t use image-name, parse, pytest, or build-secrets with non-dags. The action skips the deploy when no changed files are in root-folder or bundle-trigger-paths. See Monorepo support.

​
Deploy to named Dag bundles

On Airflow 3 Deployments, you can split your Dags into several named Dag bundles and deploy each bundle separately. Use the following inputs with deploy-type: dags-only or deploy-type: image-and-dags:
  • dag-bundle-name: The name of the Dag bundle to deploy to. The bundle must already exist on the Deployment. Requires Astro CLI 1.44.0 or later.
  • dags-path: The folder to deploy Dags from, relative to root-folder, instead of the dags folder of your Astro project.
  • no-dags-base-dir: When true, removes the Dags folder prefix from the uploaded bundle. Use this input for Airflow 3 Deployments, where the bundle root is already on sys.path. This input also works with deploy-type: infer.
These inputs require deploy-action 0.17.0 or later. To deploy several Dag bundles from one repository, add one step for each bundle. With dags-path set, a dags-only step deploys only when files in its own dags-path change. With Astro CLI 1.45.0 or later, a dags-only deploy with dags-path doesn’t need an Astro project, so your bundles can be outside it. Leave root-folder empty, set dags-path relative to the repository root, and don’t set parse or pytest. The following example deploys the image from astro-project and two named Dag bundles from bundles/:
The action rejects the following combinations:
  • dag-bundle-name or dags-path with deploy-type: infer, the default. infer deploys the image for any change outside the bundle. Use dags-only, or use image-and-dags to also deploy the image.
  • dag-bundle-name, dags-path, or no-dags-base-dir with deploy-type image-only, dbt, or non-dags, which deploy no Dags.
  • dag-bundle-name, dags-path, or no-dags-base-dir with image-name. A custom image contains its own Dags.
  • A dags-path that doesn’t exist or is outside the repository.

​
Custom images

If you set image-name, the action deploys your custom image as you built it. Starting with deploy-action 0.17.0, the action fails if you combine image-name with any of the following inputs:
  • deploy-type: dags-only or deploy-type: non-dags
  • parse or pytest, with deploy-type infer or image-and-dags
  • build-secrets

​
Monorepo support

If your Astro project lives in a monorepo, use the following inputs to control how the action checks out your repository and determines whether to trigger a deploy:
  • sparse-checkout: Limits the GitHub checkout to specific folders, typically the same value as root-folder. Use this input to reduce checkout size in large monorepos.
  • image-trigger-paths: Lists paths outside root-folder that also trigger a deploy when changed, for example generated files that get copied into the image at build time. Applies to the infer, image-and-dags, and image-only deploy types.
  • bundle-trigger-paths: Lists paths outside root-folder that also trigger a bundle deploy when changed, for example shared dbt macros. Applies to the dbt and non-dags deploy types. Requires deploy-action 0.17.0 or later.
  • skip-unchanged: Set to false to always run the deploy dictated by deploy-type, instead of skipping when no changed files fall under root-folder, dags-path, image-trigger-paths, or bundle-trigger-paths. This input replaces the deprecated deploy-image: true input. Starting with deploy-action 0.17.0, this input also applies to the dbt and non-dags deploy types.
For dbt and non-dags deploys, the action also deploys the bundle when it can’t determine the changed files, for example on a manual workflow dispatch. See Configuration options in the Deploy Action README for full details and examples.