Track DORA Metrics
      Back to home
      1. Help Center
      2. Using Swarmia
      3. Track DORA Metrics

      Generate deployments from GitHub checks

      Swarmia can generate deployments automatically from your CI/CD pipeline, using GitHub checks.

      Configuration

      Deployments can use Check Runs from GitHub's Checks API as the input data.

      1. Start by creating an application and giving it a name
      2. Select "GitHub check tracks deploys" as the Deployment source.
      3. Select the repository, check, and branch which most accurately reflect your production deployment events.
      4. Confirm the amount of deployment data to be created, and Save

      help-center-deployment-checks-form

      Not using GitHub checks yet?

      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.

      💡 Tip: You can also use the Deployments API to pass deployments to Swarmia.

      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).

      ⚠️ Note: You're likely going to need administrative permissions for any GitHub repository when integrating a CI system to use GitHub checks.

      Why my failed GitHub checks are not showing up in Swarmia as deployments?

      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.`.

      Connecting common CI systems to GitHub

      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.

      CircleCI

      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.

      Prerequisites:

      • 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

      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).

      Jenkins

      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

      Bamboo

      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.