If your release workflow already makes use of GitHub Deployments, Swarmia can automatically track those deployments.
Configuration
Deployment Insights can use Check Runs from GitHub Deployments as the input data.
- Start by creating an application and giving it a name
- Select "GitHub Deployments" as the Deployment source.
- Select the repository from which you you want to track deployments.
- Confirm the amount of deployment data to be created, and Save
Not using GitHub Deployments yet?
In order to generate GitHub Deployments for your deployment workflows, ensure that the workflows indicate an environment (e.g production) as instructed by GitHub Deployments documentation. The generated deployments then reflect on https://github.com/<organization>/<repository>/deployments as shown in this example.
Why my failed GitHub deployments are not showing up in Swarmia?
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 Deployment statuses (`error`, `failure`, `inactive`, `in_progress`, `queued`, `pending`, and `success`), on the other hand, is meant for communicating the status of getting code to production. If a GitHub deployment has the status `error` or `failure,` it means that you failed to deploy code to production, not that you caused a change failure. Because of this, Swarmia only ingests deployments when they have the status `success.`.