Fetch Historical GitHub Data for DORA Metrics #2189
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
hadar-co
requested changes
May 7, 2025
|
|
||
| Organizations using Port often want to track **engineering metrics** like DORA. These metrics provide insight into how teams build, test, and deploy software. But to calculate meaningful metrics, you first need data. | ||
|
|
||
| This guide walks you through how to **fetch historical GitHub data** using GitHub Actions. This data will become the foundation for building and visualizing your engineering metrics—like deployment frequency, lead time for changes, and more. |
There was a problem hiding this comment.
Suggested change
| This guide walks you through how to **fetch historical GitHub data** using GitHub Actions. This data will become the foundation for building and visualizing your engineering metrics—like deployment frequency, lead time for changes, and more. | |
| This guide demonstrates how to **fetch historical GitHub data** using GitHub Actions. | |
| This data will become the foundation for building and visualizing your engineering metrics such as deployment frequency, lead time for changes, and more. |
| This guide walks you through how to **fetch historical GitHub data** using GitHub Actions. This data will become the foundation for building and visualizing your engineering metrics—like deployment frequency, lead time for changes, and more. | ||
|
|
||
| ### Use cases | ||
| - These workflows are designed for **one-time or on-demand use** to help you backfill historical data. This is especially useful when onboarding to Port or when certain types of data (e.g., old PRs, releases, workflow runs) were never synced in real time. |
There was a problem hiding this comment.
Suggested change
| - These workflows are designed for **one-time or on-demand use** to help you backfill historical data. This is especially useful when onboarding to Port or when certain types of data (e.g., old PRs, releases, workflow runs) were never synced in real time. | |
| These workflows are designed for **one-time or on-demand use** to help you backfill historical data. This is especially useful when onboarding to Port or when certain types of data (e.g., old PRs, releases, workflow runs) were never synced in real time. |
| - `PORT_CLIENT_ID` - Your port `client id` [How to get the credentials](https://docs.port.io/build-your-software-catalog/sync-data-to-catalog/api/#find-your-port-credentials). | ||
| - `PORT_CLIENT_SECRET` - Your port `client secret` [How to get the credentials](https://docs.port.io/build-your-software-catalog/sync-data-to-catalog/api/#find-your-port-credentials). | ||
|
|
||
| ## Tracking deployments |
There was a problem hiding this comment.
Suggested change
| ## Tracking deployments | |
| ## Track deployments |
|
|
||
| ## Tracking deployments | ||
|
|
||
| In this section, we focus on **deployment tracking**. A deployment refers to shipping code to a live environment such as Production, Staging, or QA. We'll provide ready-to-use GitHub Actions that extract historical deployment-related data and send it to Port. |
There was a problem hiding this comment.
Suggested change
| In this section, we focus on **deployment tracking**. A deployment refers to shipping code to a live environment such as Production, Staging, or QA. We'll provide ready-to-use GitHub Actions that extract historical deployment-related data and send it to Port. | |
| In this section, we focus on **deployment tracking**. | |
| A deployment refers to shipping code to a live environment such as Production, Staging, or QA. We'll provide ready-to-use GitHub Actions that extract historical deployment-related data and send it to Port. |
|
|
||
| ### Data model setup | ||
|
|
||
| You will need to manually create blueprints for Github **Repository** and **User** as you will need them when defining the self service actions. |
There was a problem hiding this comment.
these 2 blueprints are created by default with the github integration, no? Let's clarify in the prerequisites that it needs to be installed.
Then in this section, let's clarify that these blueprints are created.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
Added docs pages
Please also include the path for the added docs
/)/platform-overview/port-components/blueprint)Updated docs pages
Please also include the path for the updated docs
/)/platform-overview/port-components/blueprint)