Github Actions

How to connect Github Actions to Multitudes

Setup

Set up our GitHub Actions integration to get insights like Deployment Frequency , Change Lead Time through to deploy, Deploy Time, and Deployment Failure Rate.

You can use either our Deployments API or our GitHub Actions integration to provide us with data about deployments. If you already have our Deployments API integration configured, you will need to revoke that action token before connecting with our GitHub Actions integration.

1. In the Multitudes app, go to Settings > Integrations and click on the Connect button in the Github and Github Actions card

   
2. On the resulting modal, click to configure Github Actions data

   
3. On the next page of the modal, you can choose either the “Environment/Deployments” or “Workflows” option, based on how you use GitHub Actions. See details below the image.

Don't know what to pick? Here are some common scenarios!

“The change is deployed when it has been deployed to a certain environment/s"

• This sounds like you are using GitHub Action’s “Environments” feature, and therefore their “Deployments” feature, so you would select "Environment/Deployments"

• In your case, the best way for us to track a “deployment” is for you to tell us which Environment/s are your production environments in each repository. You'll see this in the next step.

• Note that within one workflow run, you can have more than 1 successful deployment (e.g., you could use the same workflow to deploy to dev, staging, and prod). Therefore it’s important to understand how we calculate deployment metrics when you’ve selected this option.

A note on historical data availability: Due to constraints on GitHub’s API, we will not be able to fetch historical deployment data for this option.

• This is only an issue if you onboarded to Multitudes recently (i.e., if you onboarded to Multitudes a while ago but didn't configure GitHub Actions until today, then today we can still access your historical deployment data).

• While most charts will have 6 weeks of historical data from before you onboarded onto Multitudes to get you started, charts relating to deployments will only have data from onboarding onwards.

• Also note that it might look like your Change Lead Time increases from the date that you onboard, because from that point onwards, change lead time will include deploy time based on your deployments data.

• Here's a concrete example

  • You onboard onto Multitudes (install our GitHub app) on 1 June, from this point on we start accumulating real-time events data

  • We also pull 6 weeks of historical data, back to 16 May, to get you started

  • On 8 June, you configure GitHub Actions

  • We will only show deployment data from June 1 to June 8

“The change is deployed when a specific workflow(s) has run”

• This sounds like you are not using GitHub Action’s “Environments” feature

• In your case, the best way for us to track a “deployment” is for you to tell us which Workflow/s are the ones that deploy to your production environment for each repository. You'll see this in the next step.

A note on historical data availability: we will have access to historical data (the 6 weeks of data from before you onboarded onto Multitudes), but only the latest attempt in the historical data. This means that for example, if an attempt to deploy to production succeeded at 12pm, but for some reason you re-ran the workflow again successfully at 1pm, 1pm will be what is captured as the Deploy Time for that PR, even though it actually got deployed earlier at 12pm. This is a constraint on the historical data from the GitHub API.

With respect to data availability in either case, once you have integrated GitHub Actions, we will have real-time data, and will take the first successful attempts to deploy to production going forward (since that is when the change is first available to customers).

1. Once you’ve made a selection, the following page of the modal will prompt you for further configuration. In either case you will:

• First identify which repository

• Then within that repository, select either relevant environment or workflow

• Click the "Save" button

Screenshot for if you selected “Environment/Deployments

Screenshot for if you selected “Workflows

1. All done!