stenjo / devops-metrics-action Goto Github PK

Github action to calculate dora metrics

License: MIT License

TypeScript 100.00%

devops-metrics-action's Introduction

Get DevOps Metrics from GitHub project issues and releases

This GitHub Action will calculate a set of DevOps Research and Assessment (DORA) metrics based on status and dates from commits and issues.

Inputs

`repo`

Repository from where to read issues and statuses. List one or more repositories, either as one single string, as an array or all separated by newlines. Valid formats are:

repo: my-repo

repo: [my-repo, my-other-repo]

repo: 
    my-repo
    my-other-repo

Default repo value is repo where action is installed if no repos are spefied.

`owner`

Owner of the repository. Default is current repository owner or organisation. Only one is handled.

`token`

Access token for the repository.

`logging`

Set to true to make event logs of metrics source avaiable.

`filtered`

Set to true to filter pulls to only include feat and fix as basis for the lead time metric

Outputs

`deploy-frequency`

Rate of deploys (tagged releases) per week. Decimal number. Elite performing teams has 7 as target (daily- or on-demand release)

deploy-frequency-log - a list of releases forming the basis for the metric, if logging is enabled.

`lead-time`

Time from issue is set to status doing until linked pull-requestis merged to main branch. Number in days (Integer)

lead-time-log - a list of pull requests with matching first commit and re forming the basis for the metric, if logging is enabled.

`change-failure-rate`

Number of registered issues tagged as bugs divided by number of release tags last month. By counting the bugs (github issues tagged as bug) between releases the last month and average this, we get the failures over releases rate. Number in range 0 - 100 (%)

`mttr`

Mean time to restore. This metric is calculated based on the time between the last release before an issue tagged as a bug and the first release after the bug is closed. For this to work correctly we must assume github issues are created for all unwanted issues in production and that all changes to production is done through releases. Number in hours (integer)

Usage

Simplest possible use of this action is something like this:

name: Calculate DevOps Metrics

on: 
  schedule:
  - cron: '30 0 * * *'

jobs:
  update-metrics:
    runs-on: ubuntu-latest
    name: Checking the dora metrics
    steps:
      - name: DevOps Metrics from GitHub
        uses: stenjo/devops-metrics-action@v1
        id: dora
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

This will base calculations on the repo where the workflow is installed and run 12:30 AM every day. To access the outputs anywhere in the workflow, refer to the output of the calculation step via variable format ${{ steps.dora.outputs.deploy-rate }}. Something like:

      - name: Get the output rate
        run: echo "The deploy rate was ${{ steps.dora.outputs.deploy-rate }}"      # Use the output from the `dora` step

More complex examples may be found in .github/workflows/badges.yaml and .github/workflows/dora.yaml

Badges at the top of this file is generated through the badges.yaml workflow. More on this in Create badges for metrics output

devops-metrics-action's People

Contributors

Watchers

Forkers

shubham-elanco

devops-metrics-action's Issues

docs: add example usage

Add description of usage

feat: handle several repos

Some times issues managed by projects are created on more than one repo. Make sure action handles issues and releases on more than one repo.

Suggested format of input:

repo: ['repo1','repo2']
or

repo:
  - repo1
  - repo2

feat(lead time): add option to get list of issues/commits/releases that the lead time metric is based on

Lead time is the average time between the first commit for a change (pull request) and the release in which the change is deployed, for all changes the last month.

Add option to list the events (first commit, pr, release) that the metric is based on, by setting logging flag to true that produces the list as action output that can be uploaded for inspection.

fix(issues): not all issues are fetched going back 1 month

When having a larger number of issues, all issues must be fetched in pages as the maximum delivered for one page is 100 issues.

gh api  -H "Accept: application/vnd.github+json"  \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -XGET  /repos/stenjo/devops-metrics-action/issues -f state=all -f per_page=100 -f page=2

docs(test): coverage in pull-request

refactor(action): move to typescript template

Update node version from 16 to 20

@stenjo https://github.com/stenjo/devops-metrics-action/blob/main/action.yml#L40
Since action used node 16(deprecated). It is giving warning to update it to v20

feat(lead time): add option to count only feat and fix issues

When calculating lead-time, all PR's are counted - including release-please's chore(main): release x.x.x. These issues should maybe not be counted as they are automatic and does not really connect to delivery rate.

Suggest to add a feature that enables only features and fixes to be counted.

Handle empty release and issue lists

What happens when there are no releases?
Add handling of these situations and add better error checking for data

fix: include also closed issues in issue list

/repos/stenjo/dora/issues?q=state=all

feat(test-coverage): add coverage in pr and compare with main

Using https://github.com/marketplace/actions/comment-test-coverage

Add example creating badges for metrics data

Would be good with a description on how to create badges for each metric where badge colour indicates if metric is within limits.

Calculate lead-time of issues

On Github projects it is feasible that the issues may be used as the source.
Have to calculate time from issue is started working on until closed and deployed in main.

feat(deploy rate): add option to get list of issues/commits/releases that deploy frequency is based on

Rate of deploys (tagged releases) per week.
Decimal number. Elite performing teams has 5 as target (daily- or on-demand release)

The basis for this metric is the number of releases cretated last month, divided by 30/7, or more specificly:

Math.round(this.monthly() * 700) / 3000

Add option to get list of events (releases) this is based on, by setting LOGGING option to true, that enables a list output from action that can be uploaded for inspection.

deploy frequency #237
lead time #238
change failure rate
mean time to restore

stenjo / devops-metrics-action Goto Github PK

devops-metrics-action's Introduction

Get DevOps Metrics from GitHub project issues and releases

Inputs

repo

owner

token

logging

filtered

Outputs

deploy-frequency

lead-time

change-failure-rate

mttr