LogoLogo
Book a demoLog in
  • Swarmia documentation
  • Getting started
    • Get started in 15 minutes
    • Integrations
      • GitHub
        • GitHub Enterprise Server
        • Multiple GitHub organizations
        • Forked repositories
        • Troubleshooting
          • Reinstalling the Swarmia GitHub app
          • Updating app permissions
          • Installing Swarmia outside of GitHub Marketplace
      • Jira
        • Jira Server and Jira Data Center
        • Multiple Jira organizations
      • Linear
        • Private Linear teams
        • Disconnect Linear
      • Slack
        • Private Slack channels
      • Authentication
        • Google Single Sign-On
          • Frequently asked questions
        • Okta Single Sign-On
      • HR systems
      • Data export
        • Data cloud
        • Export data as a CSV file
      • Other integrations
        • Other issue tracker integrations
        • Other source code hosting integrations
  • Configuration and data quality
    • Teams & members
      • Creating & managing teams
        • Teams API
      • Contributors
      • Roles and permissions
      • Inviting team members
    • Pull request exclusions
    • Issue tracker configuration
      • Jira configuration
      • Jira best practices
      • Linear configuration
    • Linking pull requests to issues
    • Investment categories
    • Deployments
      • Generate deployments from merged pull requests
      • Generate deployments from GitHub deployments
      • Generate deployments from GitHub checks
      • Generate deployments via the API
        • Generate deployments for monorepos via the API
    • Sprint configuration
  • Use cases
    • Improve pull request flow
      • Pull request insights
      • Reducing pull request cycle time
      • Review code faster
      • Managing pull requests in progress with the Pull Request view
      • Diagnosing low pull request throughput
      • Analyzing pull request batch size
  • Improve your team's focus
    • Optimizing issue cycle time
    • Analyzing activity patterns on Work Log
    • Grouping activity on the Work Log view
    • Retrospective guide
  • Balance engineering investments
    • Activity and effort-based models
    • Categorizing work
    • Common problems with balancing engineering investment
  • Deliver strategic initiatives
    • Forecasting initiatives
  • Capitalize software development costs
  • Run developer experience surveys
    • Creating a survey
    • Managing surveys
    • Viewing and sharing survey results
    • How we show your survey responses
    • Survey communication guide and templates
  • Track DORA metrics
    • Automatic change failure detection
    • How Swarmia links PRs to deployments
  • Coach software developers
  • Get visibility into your CI pipeline
  • Continuous improvement
    • Working agreements
  • Notifications
    • Team notifications
    • Personal notifications
  • Retrospectives with Swarmia
  • Metrics & definitions
    • Pull request cycle time
      • What's the difference between "Change lead time" and "Pull request cycle time" metrics in Swarmia?
    • Issue cycle time
      • Defining issue lifecycle and cycle time
    • Developer effort (FTEs)
  • DORA metrics
    • Change lead time
    • Deployment frequency
    • Mean time to recovery
    • Change failure rate
  • Throughput
  • Time to deploy
  • Batch size
  • Flow efficiency
  • Scope creep
  • Sprints
  • Frequently asked questions
    • How do you treat weekends in metrics?
    • Tracking squashed commits
    • How do merge queues affect my metrics?
    • Why is my commit not visible in Swarmia?
    • How do I account for people leaving my organization?
  • Resources
    • Security & data retention
      • Data security
      • Data access
      • Swarmia IP Addresses
      • Single Sign-On (SSO) / SAML
      • Can I get a copy of the SOC 2 Type II audit report?
      • Deleting your organization
  • Pricing & plans
    • Compare plans
    • Free plan
    • Do I need a credit card to start a free trial?
    • What are the differences between the individual modules and the standard plan?
    • How do you determine the number of developers for billing?
    • What happens to customers with the Lite plan after the December 2024 pricing and plan change?
  • Changelog
On this page
  • Option 1: Differentiate based on which files changed
  • Option 2: Tell us which commits were deployed

Was this helpful?

  1. Configuration and data quality
  2. Deployments
  3. Generate deployments via the API

Generate deployments for monorepos via the API

How to setup the Swarmia deployments API to track deployments from monorepos

PreviousGenerate deployments via the APINextSprint configuration

Last updated 13 days ago

Was this helpful?

Swarmia supports tracking deployments from (repositories that contain code for multiple applications that are deployed separately) with some additional setup. For this use case, you will need to use the deployments API.

With monorepos, the challenge is in determining which commits (and thus pull requests) belong to which deployment apps. The deployments API provides two ways for this.

Option 1: Differentiate based on which files changed

The deployments API supports filtering associated PRs based on which files they touch via the filePathFilter field. This can be a good approach if your monorepo has a separate folder for each service. For example, let's say that you have a service defined in services/service-1.

When this service is deployed, you would send a deployment to the deployments API with these fields:

"appName": "monorepo/service-1"
"filePathFilter": "service-1/"
"commitSha": "fc24ab8620f41a0ece6541004f1b4e610bc5767b"

We will then look up all the commits between this new deployment and the previous deployment of the same app (based on the commitSha fields). We will find PRs associated with the commits, and then we will filter the PRs based on the filePathFilter so that only PRs that include changes to service-1/ will be included in the deployment.

As a result, PRs from other services in the monorepo will be ignored and your DORA metrics will be tracked correctly.

See the full docs for filePathFilter .

Option 2: Tell us which commits were deployed

If you need even more granular control than what filePathFilter provides, you can use your own logic to determine which commits (and thus pull requests) should be included in the deployment of the service.

For this you would send us data like this

"appName": "monorepo/service-1"
"commitSha": "fc24ab8620f41a0ece6541004f1b4e610bc5767b"
"includedCommitShas": [
  'fc24ab8620f41a0ece6541004f1b4e610bc5767b',
  '9f08ee13c1ca9fb4ac9635290ab754f734d4c7f2',
  '83a129c486d70d2ae855a7b69110e26649d2ed98'
]

We will then use the includedCommitShas to determine which pull requests should be included in this deployment.

You can also use includedCommitShas in combination with filePathFilter if you for some reason need to.

For the pull request detection to work, it is required that you include the "merge commit hash" of each deployed pull request in the list of included commits. You can find the merge commit hash from the GitHub UI (see screenshot below)

See the full docs for includedCommitShas .

monorepos
here
here