LogoLogo
HomeAbout usSign up
  • Introduction
  • AttentionSet
    • AttentionSet Best Practices
    • How to View AttentionSet for Others
    • How to Manually Change Attention
    • AttentionSet Chrome extension
    • Attention reasons
    • AttentionSet Slack Home Page
  • Releases
    • Getting Started with Releases
    • Concepts for Releases
      • Terminology for Releases
      • Two-step delivery
      • Rollbacks
      • Cherry-picks
      • Dogfood, Canary and Rollout
      • Release notes
    • How-to Guides for Releases
      • How to Create a Release Project
      • How to Configure Environments
      • How to Create a Scheduled Release
      • Create Custom Workflow Parameters
      • How to Manage Cherry-Picks
      • How to Resolve a Cherry-Pick Failure
      • Working with your CI / CD
        • GitHub Actions workflow
        • Buildkite workflow
    • API Reference for Releases
  • FlexReview
    • Getting Started with FlexReview
    • How to Onboard a Large Org
    • Concepts for FlexReview
      • Read-Only Mode in FlexReview
      • Recursive Ownership in FlexReview
      • Reviewer suggestion and assignment
      • FlexReview Teams and SLO Management
      • Validation in FlexReview
    • How-to Guides for FlexReview
      • How to Get a Reviewer Suggestion
      • How to Exclude Reviewers
      • How to Set Up Team Rules
      • Whitelist Teams for Review Assignment
      • Troubleshoot Reviewer Assignment
      • PagerDuty Integration for Reviewers
      • How to Set Up FlexReview Validation
      • Recommended Slack Notification Settings
      • How to Exclude OOO Reviewers
    • FlexReview Reference
      • Configuration
      • Slash commands
      • Expert scoring algorithms
      • Slack Notifications
      • Out of Office User Exclusion
    • FlexReview Roadmap
  • MergeQueue
    • Getting Started with MergeQueue
    • Merge Rules
    • How-to Guides for MergeQueue
      • How to Configure Base Branches
      • How to Customize Required Checks
      • How to Set Up Fast-Forwarding
      • How to Set Up Pre-Queue Conditions
      • How to Queue / Dequeue via API
      • Pause / Unpause Queues via API
      • Slash Commands Using GitHub Comments
      • How to Customize Sticky Comments
      • Require an Aviator Status Check
      • Backport a PR
      • How to Configure ChangeSets
      • Custom Integrations
        • GitHub Integration
      • How to Create Personal Access Tokens
      • How to Set Up SAML Configuration
        • Microsoft Active Directory
      • How to Merge Stacked PRs
      • How to Block Pull Request Mergeing with Slash Commands
    • Concepts for MergeQueue
      • Queue Modes
      • Pull Request Lifecycle
      • Analytics
      • Parallel Mode
      • CI Status Requirements
      • MQ Created Branches
      • Batching
      • Managing flaky tests
      • Fast-forwarding
      • Pre-Queue Conditions
      • Sticky Comments
      • Backporting
      • Paused Queues
      • Affected Targets
        • Directory-Based Affected Targets
        • nx based affected targets
        • GitHub Actions based Affected Targets
      • ChangeSets
        • Global CI Validation
        • ChangeSets FAQs
      • Priority Merges
        • Instant Merges
      • Merge Rules Audit Trail
      • Timeline
      • Ready Hook
      • Reduce Queue Failures From Staleness
    • MergeQueue References
      • Configuration Schema
      • Configuration Reference MergeQueue
      • GitHub Slash Commands
      • Status Codes
  • Stacked PRs CLI
    • Quickstart for Stacked PRs CLI
    • CLI Installation
    • How-to Guides for Stacked PRs CLI
      • How to Create Stacked PRs in CLI
      • How to Navigate & Modify Stacked PRs
      • Add Commits in the Stack
      • How Split a Commit in CLI
      • How to Split and Fold Pull Requests
      • How to Rename a Branch in CLI
      • How to Adopt a Branch in CLI
      • Orphan a Branch with Aviator CLI
      • How to Do Git Subcommand Aliasing
      • How to Create an Access Token
      • How to Set Up Auto Completion in CLI
      • How to Use Editor Plugins in CLI
    • Concepts for StackedPRs CLI
    • How to Rebase and Sync with GitHub
    • Configuration for StackedPRs CLI
    • Stacked PRs FAQs and Troubleshooting
      • Working with Aviator CLI
      • Default Branch Update Master to Main
    • Manpages for Stacked PRs CLI
      • av(1)
      • av-adopt Command Guide
      • av-auth-status(1) in CLI
      • av-stack-branch(1) in CLI
      • av-commit-create(1) in CL
      • av-stack-diff(1) in CLI
      • av-fetch(1) in CLI
      • av-git-interaction Command Guide
      • av-init(1) in CLI
      • av-stack-next(1) in CLI
      • av-orphan Command Guide
      • av-pr-status(1) in CLI
      • av-pr-create(1) in CLI
      • av-stack-prev(1) in CLI
      • av-stack-reorder(1) in CLI
      • av-reparent Command Guide
      • av-restack Command Guide
      • av-commit-split(1) in CLI
      • av-switch Command Guide
      • av-stack-sync(1) in CLI
      • av-stack-tidy(1) in CLI
      • av-stack-tree(1) in CLI
    • Aviator CLI Major Releases
      • Aviator CLI v0.1.0 Release Notes
  • Aviator's Chrome Extension
  • Pilot Automated Actions
    • Scheduled Events
    • JavaScript Execution
    • Pilot Automated Actions Reference
      • GitHub Reference
      • MergeQueue Reference
      • Slack Reference
  • API and Integrations
    • Slack Integration Guide
    • GraphQL API Quickstart
    • Prometheus Metrics Setup for GCP
    • Reference
      • JSON API
      • GraphQL
      • Webhooks
      • Monitoring Metrics
  • Manage
    • Access Management
    • GitHub App Permissions
    • Security
      • Aviator Agents Data Usage & Retention Policy
    • On-Premise Installation
      • GitHub App for On-Prem
      • GitHub OAuth for On-Prem
      • Use Helm Instructions
      • Use Docker Compose Instructions
      • Prometheus endpoint
      • Slack Integration for On-Premise
      • Google SSO Login for On-Prem
    • FAQs
      • Troubleshooting GitHub app connection
      • MergeQueue FAQs
      • Billing FAQs
Powered by GitBook
On this page
  • Authentication
  • Build workflow
  • Option A - Using Two-step workflow
  • Option B - Skipping build step
  • Deploy workflow

Was this helpful?

  1. Releases
  2. How-to Guides for Releases
  3. Working with your CI / CD

GitHub Actions workflow

Use our guide to set up GitHub Actions build and deploy to manage releases in Aviator. Instructions on authentication, building and deploying workflows.

PreviousWorking with your CI / CDNextBuildkite workflow

Last updated 7 months ago

Was this helpful?

Use this guide to configure GitHub actions build and deploy steps to manage releases in Aviator. To use Aviator Releases, we recommend have separate steps for the . You may still use it as a single step, in which case the creation of Release (the build part) will be a no-op.

Authentication

  1. Generate an Aviator API token at

  2. Set up environment variables and secrets for your GitHub repo at Settings > Secrets and Variables > Actions

    1. Add a repository secret AVIATOR_API_TOKEN as the API token generated above

Build workflow

Option A - Using Two-step workflow

  1. When getting started with Aviator Releases, we recommend duplicating your existing workflow files in GitHub.

    1. NOTE: The new workflows need to be merged to your default branch in order to take effect

  2. Aviator triggers GitHub using . This workflow requires specifying the following params in your workflow file:

on:
  workflow_dispatch:
    inputs:
      aviator_release_cut_id:
        description: "Database ID of release cut"
        required: false
        type: string
      aviator_release_cut_commit_hash:
        description: "Commit SHA, branch name, or tag of the HEAD to be built"
        required: false
        type: string
      aviator_release_candidate_version:
        description: "Name of the version"
        required: true
        type: string
  1. Add a workflow job at the beginning of the build workflow to sync the workflow run ID with Aviator. This helps Aviator track the CI action that’s running your build.

    steps:
      - if: inputs.aviator_release_cut_id != ''
        name: Sync workflow run ID via Aviator API
        uses: fjogeleit/http-request-action@v1
        with:
          url: 'https://api.aviator.co/api/v1/sync-build-github-action'
          method: 'POST'
          bearerToken: ${{ secrets.AVIATOR_API_TOKEN }}
          data: '{"release_cut_id": "${{ inputs.aviator_release_cut_id }}", "workflow_run_id": "${{ github.run_id }}"}'
    
      - name: Checkout the repository
        uses: actions/checkout@v4
        with:
          # if custom commit_sha is not defined, this should fall back to the head branch
          ref: "${{ inputs.aviator_release_cut_commit_hash }}"
          lfs: true
          submodules: 'recursive'
  2. After this you can keep your regular builds steps as is. Make sure to tag the build artifacts with the release version using ${{inputs.aviator_release_candidate_version}} so that you can refer to them in the deployment step.

Option B - Skipping build step

If you want to skip the Build step entirely, select “Not Configured” in the Build step:

In this configuration mode, as soon as a Release is cut, the build is marked as completed. Then you can set up deployment as a separate step.

Deploy workflow

  1. Similar to the Build step, duplicate the Deploy step as well and apply the following parameters in your workflow file. Note that these are different than the build params:

on:
  workflow_dispatch:
    inputs:
      aviator_deployment_id:
        description: "Database ID of deployment"
        required: false
        type: string
      aviator_release_cut_commit_hash:
        description: "Commit SHA, branch name, or tag of the HEAD"
        required: false
        type: string
      aviator_release_candidate_version:
        description: "Version to deploy"
        required: true
        type: string
  1. Add a workflow job at the beginning of the deploy workflow to sync the workflow run ID with Aviator. Note that the API URL is different from the build workflow.

    steps:
      - if: inputs.aviator_deployment_id != ''
        name: Sync workflow run ID via Aviator API
        uses: fjogeleit/http-request-action@v1
        with:
          url: 'https://api.aviator.co/api/v1/sync-deploy-github-action'
          method: 'POST'
          bearerToken: ${{ secrets.AVIATOR_API_TOKEN }}
          data: '{"deployment_id": "${{ inputs.aviator_deployment_id }}", "workflow_run_id": "${{ github.run_id }}"}'
          
    	- name: Checkout the repository
        uses: actions/checkout@v4
        with:
          # if custom commit_sha is not defined, this should fall back to the head branch
          ref: "${{ inputs.aviator_release_cut_commit_hash }}"
          lfs: true
          submodules: 'recursive'
  2. After this you can keep your regular deploys steps as is. Make sure to use the same build artifacts with the release version using ${{inputs.aviator_release_candidate_version}} so that you can refer to them in the deployment step.

Now you should be ready to use Aviator Release Management!

build and deploy workflows
https://app.aviator.co/settings/workspace/integrations
workflow dispatch REST API
Skip Build step