• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      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

            Tyler T added a comment -

            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 or API, 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.

            Tyler T added a comment - 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 or API, 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.

            DavidE added a comment -

            Monorepo support is important for our business.  Please support.

            DavidE added a comment - Monorepo support is important for our business.  Please support.

            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.

            Andrew Kite added a comment - 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.

              05fa5aee2f02 Josh Campbell (Inactive)
              4c2ff7ed7f76 Kelvin T
              Votes:
              15 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated: