# Generate deployments from GitHub deployments

## Configuration

[**Deployments**](https://app.swarmia.com/metrics/deployments) can use Check runs from [GitHub deployments](https://docs.github.com/en/actions/deployment/about-deployments/deploying-with-github-actions) as the input data.

1. [**Start by creating an application**](https://app.swarmia.com/settings/deployments) 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**.

<figure><img src="https://2772466312-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMa8uBmGhQgR7MTPq9yh7%2Fuploads%2Fgit-blob-37cc959ff7e9d70b8da614077965e001f4e7fd1a%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

### Automatic deployment app creation

Swarmia automatically creates a new deployment app when receiving a GitHub deployment if there's no existing app with the same name. You can toggle this off in [Settings → Deployments → Apps](https://app.swarmia.com/settings/deployments).

<figure><img src="https://2772466312-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMa8uBmGhQgR7MTPq9yh7%2Fuploads%2FEIPzEVu5G7nvLqtffa1b%2F003361%402x.png?alt=media&#x26;token=28ee3ed5-5230-41e6-98f6-5bffeef44729" alt=""><figcaption></figcaption></figure>

## 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](https://docs.github.com/en/actions/deployment/about-deployments/deploying-with-github-actions#using-environments). The generated deployments then reflect on <https://github.com/_\\><organization>*/*\<repository>\_/deployments as shown in this example.

<figure><img src="https://2772466312-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMa8uBmGhQgR7MTPq9yh7%2Fuploads%2Fgit-blob-a0f721e92176f2dd2094042b709a6a3ea4362952%2Fimage.png?alt=media" alt="" width="563"><figcaption></figcaption></figure>

## 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](https://help.swarmia.com/use-cases/track-dora-metrics) 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.

<figure><img src="https://2772466312-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMa8uBmGhQgR7MTPq9yh7%2Fuploads%2Fgit-blob-413e7c574ce8adf0cf7be978c9c83fa3f4146c1d%2F003301%402x.png?alt=media" alt=""><figcaption></figcaption></figure>

(Only the first, real deployment gets linked PRs, which means that redeployments won't affect your [change lead time](https://help.swarmia.com/metrics-and-definitions/dora-metrics/change-lead-time) or [time to deploy](https://help.swarmia.com/metrics-and-definitions/dora-metrics/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.