-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
Compass currently doesn't fully support monorepos. While you can map components using a YAML file, the metrics are only calculated based on the repository's default branch. This makes it hard to track and calculate metrics for projects with multiple components in a single repository.
Monorepos are repositories that contain several projects or components, usually organized in a specific directory structure. Each project or component has its own lifecycle, dependencies, and configurations.
Compass combines and reports all metrics based on the default branch of the repository. This means the metrics do not accurately reflect the state of individual components. Important changes and statuses for specific components might be missed if they aren't in the default branch. This can lead to misleading data and incomplete insights.
[COMPASS-24] Support for Monorepos in Compass
While disabling metrics for mono repo projects, it would be great if metrics were calculated somewhat intelligently based on which files are affected in a PR.
Suppose the following directory structure:
- projectA
- compass.yml (→ name project-a in compass)
- projectB
- compass.yml (→ name project-b in compass)
Now any PR that touches files within the folder `projectA` would be counted towards the `project-a` in Compass,
while any any PR that touches files within the folder `projectB` would be counted towards the `project-b` in compass
| Support reference count | New: 1 |
While full monorepo support is not yet available, Compass now allows you to stop SCM powered metrics from monorepo components. Currently this is supported via the UI, API, and config-as-code not config-as-code -> https://developer.atlassian.com/cloud/compass/config-as-code/manage-components-with-config-as-code/#managing-multiple-components-with-config-as-code-in-a-single-repository
On the component overview page, select more actions (•••) then Component of a monorepo and enable this setting. This will prevent capturing activity (events, metrics) across the entire monorepo with the Bitbucket, GitHub, and GitLab integrations. In the future we'll add a property to manage this setting via configuration as code. Send events and metrics for this component using our API.
March 2025 UPDATE
This is now supported in Config-as-Code:
fields:
isMonorepoProject: true
| Remote Link | New: This issue links to "Page (Confluence)" [ 966834 ] |
| Remote Link | New: This issue links to "Page (Confluence)" [ 954136 ] |
Begun looking into Compass today. We have various repositories which are of a singular application or web-app. However we would be interested in seeing how Compass can help expose progress and health of the libraries we use across these applications. These have been setup within small MonoRepo workspaces which handle a specific set of packages. For example, We may have an Authentication repo which is a workspace housing our Authentication (interface package), and other Authentication.X and Authentication.Y (concrete implementation packages).
It would be great to see support for such a hierarchy. We have had great success with Lerna to help manage our CICD processes, and using Compass to extract useful insights for developers and managers to view would be beneficial.
| Remote Link | New: This issue links to "Page (Confluence)" [ 920229 ] |
| Assignee | New: Josh Campbell [ 05fa5aee2f02 ] |
We need also to have a way to enable the api schema synchronisation based on separated openapi.json files depending of the components on the the mono repos. It seems there's no currently inside the compass configuration to configure where to find out about the api specification and to track changes based on separated configurations.