Generate deployments from GitHub checks
Swarmia can generate deployments automatically from your CI/CD pipeline, using GitHub checks.
Last updated
Was this helpful?
Swarmia can generate deployments automatically from your CI/CD pipeline, using GitHub checks.
Last updated
Was this helpful?
Was this helpful?
Deployments can use Check Runs from GitHub's Checks API as the input data.
Start by creating an application and giving it a name
Select "GitHub check tracks deploys" as the Deployment source.
Select the repository, check, and branch which most accurately reflect your production deployment events.
Confirm the amount of deployment data to be created, and Save
In order to surface the deployment data on Swarmia, you'll need to ensure that your CI (Continuous Integration) system is properly configured to pass the Checks data to GitHub.
Luckily, most modern CI systems offer a productized means of passing this data to GitHub. There are a lot of CI apps directly available on GitHub's marketplace, which means this is likely the best place to start.
Custom implementations can also be created via GitHub's webhooks, which can be configured to exclusively listen to push and PR creation events.
When your CI system of choice has a GitHub app, you'll need to enable each repository to use the said app in the repository settings (Repository > Settings > Integrations).
The failed/succeeded deployment status in Swarmia's DORA/Deployment insights is communicating if a change (= piece of code) that you deployed to production caused a change failure. In other words, if it caused a failure in production that needed a fix in the form of a rollback, forward fix, etc. This information is based on automatic or manual change failure data.
GitHub check conclusion, on the other hand, communicates the status of getting code to production. If a GitHub check has the conclusion failure, it means that you failed to deploy code to production, not that you caused a change failure. Because of this, Swarmia only creates deployments for check when they have the conclusion success.
Please refer to your CI provider's documentation to integrate the Check Run data. Below, we go through a high-level overview of some commonly used systems.
For CircleCI, GitHub Checks are enabled on the CircleCI interface. You'll want to ensure you have the CircleCI app installed for the GitHub project, the repository configured to use the app, and sufficient access rights both on CircleCI project and the GitHub repository.
You must be using the cloud-hosted version of CircleCI.
Your CircleCI project must be using Workflows.
You must be an Admin on your GitHub repository to authorize installation of the CircleCI Checks integration.
TravisCI has a GitHub app which can be found from the Marketplace. You'll want to start by installing the app and configuring the app for the GitHub repository (Settings > Integrations).
The easiest way to integrate Jenkins checks to GitHub is to use the GitHub Checks plugin. However, you first need to authorize your Jenkins as a GitHub App
For Atlassian's Bamboo server, there's an addon for passing the Check Run data to GitHub. If your version is not compatible with the addon, you'll need to create a GitHub App to get in order to have API access to create check runs via the Checks API.