Generate deployments from GitHub deployments

If your release workflow already makes use of GitHub deployments, Swarmia can automatically track those deployments.

Configuration

Deployments can use Check runs from GitHub deployments as the input data.

1. Start by creating an application and giving it a name

2. Select "GitHub deployments" as the Deployment source.

3. Select the repository from which you want to track deployments.

4. Confirm the number of deployments to be added, and Save.

If you use GitHub deployments, Swarmia automatically configures the deployment apps for you if there's no existing app with the same name. Contact us at [email protected] if you'd like to disable this behavior.

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.

Frequently asked questions

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

The failed/succeeded deployment status in Swarmia's DORA/Deployment insights communicates if a change (= piece of code) that you deployed to production caused a change failure, ie, 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, are 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.

Why am I getting "redeployments" in Swarmia?

This is usually a symptom of a faulty configuration. You're sending multiple deployment events for each actual deployment that happens. They artificially inflate your deployment frequency, making it look higher than it actually is. Swarmia automatically flags duplicate deployments as redeployments to highlight the problem.

(Only the first, real deployment gets linked PRs, which means that redeployments won't affect your change lead time or time to deploy metrics.)

To fix the issue, check these:

• Are you accidentally sending the same environment value for deployments to different environments? (Think, for example, development, testing, staging, and production.) You can also completely remove the environment parameter from actions that don't deploy things.

• Are you accidentally sending status: success for build steps that take place before the final deployment? Swarmia only shows deployments with the success status, and we recommend using a different status, such as in_progress, for intermediate stages.