Skip to main content

Issues and PRs > Base ref | Repository

Tom Williams avatar
Written by Tom Williams
Updated over a week ago

Dataset: Issues & Pull Requests

Entity: Pull Requests, Issues

Field ID: base_ref_repository

Type: Text

Description: The repository of the base ref (destination repository).

Source: App

Transformation logic: N/A

From:

Github (PRs)

base_repository.name_with_owner

Gitlab (PRs)

target.path_with_namespace

Bitbucket (PRs)

destination.repository.full_name

Azure DevOps (PRs, Issues)

repository

JIRA

N/A

ClickUp

N/A

Trello

N/A

Reporting Use Cases

The Base Ref Repository field is essential for tracking and comparing development activities across your entire software portfolio. As a text field, it serves as a powerful tool for filtering your widgets to specific projects and as a primary dimension for cross-repository analysis.

  • Filtering and Scoping: You can create focused reports by including or excluding specific repositories.

    • Project-Specific Dashboards: Build dashboards that only show data for a single codebase by applying a filter such as Base Ref Repository = "my-main-application".

    • Microservice Analysis: If you use a consistent naming convention, you can analyze a group of related services using a regex filter like Base Ref Repository ~ "-service$".

    • Excluding Legacy Code: To focus on active development, you can exclude older or less relevant projects with a filter like Base Ref Repository != "deprecated-legacy-app".

  • Reporting and Comparison: Using Base Ref Repository as a dimension is the primary way to compare performance and activity across different projects.

    • Activity Hotspots: A bar chart with Base Ref Repository as the dimension and COUNT() as the metric will quickly reveal which repositories have the most pull request activity.

    • Performance Benchmarking: You can compare key DORA metrics across your portfolio. For instance, create a list widget with Base Ref Repository as the dimension and the average cycle time AVG(merged_at - created_at) as a metric to identify which projects have the fastest delivery pipelines.

  • Custom Formulas for High-Level Grouping: When you have many repositories, it can be useful to group them into higher-level categories for simplified reporting.

    • For example, you can create a dimension that categorizes repositories by product line using a custom formula like IF(base_ref_repository ~ '^(mobile|ios|android)', 'Mobile Apps', 'Web Apps'). This allows you to roll up metrics and understand performance at a team or portfolio level rather than just a project level.

Did this answer your question?