You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@devlake.apache.org by li...@apache.org on 2022/11/03 05:54:36 UTC
[incubator-devlake-website] 01/01: docs: add workflow filter for github ci/cd
This is an automated email from the ASF dual-hosted git repository.
likyh pushed a commit to branch likyh/github-workflow-filter
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
commit 3c8ac7e95c9b9952199a972b771c3ac6ae7d26ee
Author: linyh <ya...@meri.co>
AuthorDate: Thu Nov 3 13:54:29 2022 +0800
docs: add workflow filter for github ci/cd
---
docs/UserManuals/ConfigUI/GitHub.md | 30 +++++++++++++++++++++---------
docs/UserManuals/DORA.md | 12 +++++++-----
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/docs/UserManuals/ConfigUI/GitHub.md b/docs/UserManuals/ConfigUI/GitHub.md
index dc9a2e948..bc9104482 100644
--- a/docs/UserManuals/ConfigUI/GitHub.md
+++ b/docs/UserManuals/ConfigUI/GitHub.md
@@ -45,30 +45,37 @@ Usually, you don't have to modify this part. However, if you don't want to colle
### Step 3 - Adding Transformation Rules (Optional)
-
-
+
Without adding transformation rules, you can still view the "[GitHub Metrics](/livedemo/DataSources/GitHub)" dashboard. However, if you want to view "[Weekly Bug Retro](/livedemo/QAEngineers/WeeklyBugRetro)", "[Weekly Community Retro](/livedemo/OSSMaintainers/WeeklyCommunityRetro)" or other pre-built dashboards, the following transformation rules, especially "Type/Bug", should be added.<br/>
Each GitHub repo has at most ONE set of transformation rules.
#### Issue Tracking
+
+
- Severity: Parse the value of `severity` from issue labels.
- when your issue labels for severity level are like 'severity/p0', 'severity/p1', 'severity/p2', then input 'severity/(.*)$'
- when your issue labels for severity level are like 'p0', 'p1', 'p2', then input '(p0|p1|p2)$'
-
- Component: Same as "Severity".
-
- Priority: Same as "Severity".
-
- Type/Requirement: The `type` of issues with labels that match given regular expression will be set to "REQUIREMENT". Unlike "PR.type", submatch does nothing, because for issue management analysis, users tend to focus on 3 kinds of types (Requirement/Bug/Incident), however, the concrete naming varies from repo to repo, time to time, so we decided to standardize them to help analysts metrics.
-
- Type/Bug: Same as "Type/Requirement", with `type` setting to "BUG".
-
- Type/Incident: Same as "Type/Requirement", with `type` setting to "INCIDENT".
+#### CI/CD
+
+
+
+- Deployment Workflow: GitHub Action workflows with the name that matches the given regular expression will be considered as a Deployment workflow. For example:
+ - when your workflow name for Deployment are like 'Build', 'Build For PR' and 'Build For Dubbo 2.6', please input 'Build(.*)$'
+- Deployment Job: Usually, you don't have to fill this part and all jobs in Deployment Workflow will be considered as Deployment Job. However, if you want to collect certain GitHub job, you can give a regular expression. GitHub Action jobs **in Deployment Workflow** and **with a name that matches the given regular expression** will be considered as a Deployment Job.
+- Production Job: GitHub Action jobs with a name that matches the given regular expression will be considered as a job in the Production environment. If you leave this field empty, all data will be tagged as in the Production environment.
+
#### Code Review
+
+
- Type: The `type` of pull requests will be parsed from PR labels by given regular expression. For example:
- when your labels for PR types are like 'type/feature-development', 'type/bug-fixing' and 'type/docs', please input 'type/(.*)$'
- when your labels for PR types are like 'feature-development', 'bug-fixing' and 'docs', please input '(feature-development|bug-fixing|docs)$'
@@ -77,12 +84,17 @@ Each GitHub repo has at most ONE set of transformation rules.
#### Additional Settings (Optional)
+
+
+- PR Body Pattern: Extract the issue numbers closed by pull requests. The issue numbers are parsed from PR bodies that meet the following RegEx. For Example:
+ - ✅ Example 1: PR #321 body contains "**Closes #1234**" (PR #321 and issue #1234 will be mapped by the default RegEx)
+ - ❎ Example 2: PR #321 body contains "**Related to #1234**" (PR #321 and issue #1234 will NOT be mapped by the default RegEx)
+ - Default RegEx: `(?mi)(fix|close|resolve|fixes|closes|resolves|fixed|closed|resolved)[\s]*.*(((and )?(#|https:\/\/github.com\/%s\/%s\/issues\/)\d+[ ]*)+)`
+
- Tags Limit: It'll compare the last N pairs of tags to get the "commit diff', "issue diff" between tags. N defaults to 10.
- commit diff: new commits for a tag relative to the previous one
- issue diff: issues solved by the new commits for a tag relative to the previous one
-
- Tags Pattern: Only tags that meet given regular expression will be counted.
-
- Tags Order: Only "reverse semver" order is supported for now.
Please click `Save` to save the transformation rules for the repo. In the data scope list, click `Next Step` to continue configuring.
diff --git a/docs/UserManuals/DORA.md b/docs/UserManuals/DORA.md
index 75fe80619..2546e7572 100644
--- a/docs/UserManuals/DORA.md
+++ b/docs/UserManuals/DORA.md
@@ -65,6 +65,7 @@ In the next section, we'll demonstrate how to configure DevLake to implement DOR
### Collect GitHub & Jira data via `blueprint`
1. Visit the config-ui at `http://localhost:4000`
+
2. Create a `blueprint`, let's name it "Blueprint for DORA", add a Jira and a GitHub connection. Click `Next Step`
@@ -76,13 +77,14 @@ In the next section, we'll demonstrate how to configure DevLake to implement DOR
5. To make it simple, fields with a  label are DORA-related configurations for every data source. Via these fields, you can define what are "incidents" and "deployments" for each data source. After all data connections have been configured, click `Next Step`
- This team uses Jira issue types `Crash` and `Incident` as "incident", so choose the two types in field "incident". Jira issues in these two types will be transformed to "incidents" in DevLake.
- - This team uses the GitHub action jobs named `deploy` and `build-and-deploy` to deploy, so type in `(?i)deploy` to match these jobs. These jobs will be transformed to "deployments" in DevLake.
- 
+ - This team uses the GitHub action workflow named `Build workflow` deploy, so type in `(?i)Build` to match these workflows. Jobs in these workflow will be transformed to "deployments" in DevLake.
- Note: The following example shows where to find GitHub action jobs. It's easy to mix them up with GitHub workflows.
- 
+ 
+
+ Note: The following example shows where to find GitHub action workflow. It's easy to mix them up with GitHub jobs.
+
+ 
-
6. Choose sync frequency, click 'Save and Run Now' to start data collection. The time to completion varies by data source and depends on the volume of data.
