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
  • CI Webhook
  • Webhook Payload
  • Global CI Status Check
  • Report CI global status check
  • Multiple Global CI Checks

Was this helpful?

  1. MergeQueue
  2. Concepts for MergeQueue
  3. ChangeSets

Global CI Validation

Discover the Global CI Validation setting in MergeQueue ChangeSets. It enables Aviator to issue webhooks you can use to trigger CI tests for pre-merge checks.

Along with the CI on each individual change, you may have CI tests you would like to run on the ChangeSet as a whole before the PRs are merged. These tests can target integration-level functionality to test that all these PRs work together. Aviator offers this using a global CI framework. When you enable this setting, Aviator issues webhooks that you can use to trigger CI tests for these pre-merge checks on a ChangeSet.

CI Webhook

Once all the PRs are added to the ChangeSet, you can trigger a Global CI by clicking the "Start CI" button on the ChangeSet page. This will send a webhook to the configured Webhook endpoint. The webhook will provide information about the related repos, branch names, and SHAs to be used for the CI. The payload will be in json format with the following parameters:

Webhook Payload

Parameter
Description

change_set_id

Integer. Identifier for ChangeSet.

status_run_id

Integer. Represents a unique ID for the status run. Each time the webhook is triggered, a new Status Run ID is issued. This will be used to track the status of the CI.

pull_requests

A list of objects representing each PullRequest in the ChangeSet. Each object has the following parameters below:

>number

Integer. PR Number associated with the action.

>base_branch

String. Name of the base branch associated with the PR.

>head_branch

String. Name of the head branch associated with the PR.

>commit_sha

String. The SHA of the latest commit on the branch.

>author

String. The GitHub username of the PR author.

>repo

String. The GitHub repo name represented as org_name/repo_name.

owner

The owner of the ChangeSet. This typically represents the user who created the ChangeSet. Contains the following parameter:

>email

String. The email address of the owner.

custom_attributes

Object. A Dictionary of key-values as specified in the global and local parameters.

{
  "action": "changeset_start_ci",
  "change_set_id": 100,
  "status_run_id": 150,
  "pull_requests": [
    {
      "number": 1196,
      "head_branch": "mq-25108-1",
      "base_branch": "master",
      "commit_sha": "6705fd2483b1ceaaaa10bb4c34517c38d9fb6a02",
      "author": "mq-demo",
      "repo": "aviator/mergequeue-demo"
    },
    {
      "number": 4114,
      "head_branch": "mq-89706-1",
      "base_branch": "master",
      "commit_sha": "abf02ccc860eecf2d90adf7ca39d72f25479228f",
      "author": "mq-demo",
      "repo": "aviator/mergequeue-changeset"
    }
  ],
  "owner": {
    "email": "demo@mergequeue.com"
  },
  "custom_attributes": {
    "hello": "world",
    "trunk": "master"
  }
}

Note: This webhook should return a valid HTTP 200 response. If an invalid status code is returned, Aviator will consider the CI as "failed".

Note: The webhook payload only includes PRs that have been added to the ChangeSet. There will be no associated entry in the webhook payload for PRs that are not included in the ChangeSet.

Global CI Status Check

Once the global CI is triggered, your service should report the status check back using the status_run POST endpoint:

Report CI global status check

POST https://api.aviator.co/api/v1/status_run

Example:

curl -X POST -H "Authorization: Bearer " -H "Content-Type: application/json" https://api.aviator.co/api/v1/status_run -d '{ "status_run_id": 8, "state": "success", "name": "full-build", "message": "Build successful", "target_url": "https://example.com/full-build/8" }'

Query Parameters

Name
Type
Description

status_run_id*

Integer

Represents a unique ID for the status run. Each time the webhook is triggered, a new Status Run ID is issued. This will be used to track the status of the CI.

state*

String

Should be error, failure, pending or success.

name*

String

Name of the status check to be displayed in the Aviator dashboard.

message

String

Message describing the status.

target_url

String

A URL associated with the status run. This will be linked from the Aviator dashboard for users to click on for details.

{
  "change_set_id": 2,
  "message": "Build successful",
  "name": "full-build",
  "state": "success",
  "status_run_id": 8,
  "target_url": "https://example.com/full-build/8"
}

Multiple Global CI Checks

You can run multiple global status checks and report them separately for the same status_run_id using unique name properties. Each of these unique checks are reported back as status checks on every PR in the ChangeSet.

PreviousChangeSetsNextChangeSets FAQs

Last updated 3 months ago

Was this helpful?