This is an automated email from the ASF dual-hosted git repository.
zhangliang2022 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
The following commit(s) were added to refs/heads/main by this push:
new c609df404 fix some typo in `docs/DeveloperManuals` and
`docs/GettingStarted` (#220)
c609df404 is described below
commit c609df404d0aa25f9abbf30b6c1b7faf67786467
Author: mindlesscloud <[email protected]>
AuthorDate: Wed Sep 21 21:36:56 2022 +0800
fix some typo in `docs/DeveloperManuals` and `docs/GettingStarted` (#220)
* fix some typo
* Update E2E-Test-Guide.md
* Update PluginImplementation.md
Co-authored-by: Yumeng Wang <[email protected]>
---
docs/DataModels/DevLakeDomainLayerSchema.md | 66 +++++++++++++--------------
docs/DeveloperManuals/Dal.md | 4 +-
docs/DeveloperManuals/E2E-Test-Guide.md | 7 ++-
docs/DeveloperManuals/PluginImplementation.md | 4 +-
docs/DeveloperManuals/TagNamingConventions.md | 2 +-
docs/GettingStarted/RainbondSetup.md | 4 +-
6 files changed, 43 insertions(+), 44 deletions(-)
diff --git a/docs/DataModels/DevLakeDomainLayerSchema.md
b/docs/DataModels/DevLakeDomainLayerSchema.md
index 5116b7af0..e4e807363 100644
--- a/docs/DataModels/DevLakeDomainLayerSchema.md
+++ b/docs/DataModels/DevLakeDomainLayerSchema.md
@@ -70,9 +70,9 @@ If you want to learn more about plugin models,please visit
[PluginImplementation
An `issue` is the abstraction of Jira/Github/GitLab/TAPD/... issues.
| **field** | **type** | **length** | **description**
[...]
-| :-------------------------- | :------- | :--------- |
:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
+| :-------------------------- | :------- | :---------
|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
| `id` | varchar | 255 | An issue's `id` is
composed of < plugin >:< Entity >:< PK0 >[:PK1]..." <ul><li>For Github issues,
a Github issue's id is like "github:GithubIssues:< GithubIssueId >". Eg.
'github:GithubIssues:1049355647'</li> <li>For Jira issues, a Github repo's id
is like "jira:JiraIssues:< JiraSourceId >:< JiraIssueId >". Eg.
'jira:JiraIssues:1:10063'. < JiraSourceId > is used to identify which jira
source the issue came from, since DevLake users [...]
-| `issue_key` | varchar | 255 | The key of this issue.
For example, the key of this Github
[issue](https://github.com/merico-dev/lake/issues/1145) is 1145.
[...]
+| `issue_key` | varchar | 255 | The key of this issue.
For example, the key of this Github
[issue](https://github.com/merico-dev/lake/issues/1145) is 1145.
[...]
| `url` | varchar | 255 | The url of the issue.
It's a web address in most cases.
[...]
| `title` | varchar | 255 | The title of an issue
[...]
| `description` | longtext | | The detailed
description/summary of an issue
[...]
@@ -85,17 +85,17 @@ An `issue` is the abstraction of
Jira/Github/GitLab/TAPD/... issues.
| `severity` | varchar | 255 | The severity level of
a bug-issue. This field only supports Github plugin for now. The value is
transformed from Github issue labels by the rules set according to the user's
configuration of .env by end users during DevLake installation.
[...]
| `parent_issue_id` | varchar | 255 | The id of its parent
issue
[...]
| `epic_key` | varchar | 255 | The key of the epic
this issue belongs to. For tools with no epic-type issues such as Github and
Gitlab, this field is default to an empty string
[...]
-| `original_estimate_minutes` | int | | The orginal estimation
of the time allocated for this issue
[...]
-| `time_spent_minutes` | int | | The orginal
estimation of the time allocated for this issue
[...]
-| `time_remaining_minutes` | int | | The remaining time to
resolve the issue
[...]
-| `creator_id` | varchar | 255 | The id of issue
creator
[...]
-| `creator_name` | varchar | 255 | The name of the
creator
[...]
-| `assignee_id` | varchar | 255 | The id of issue
assignee.<ul><li>For Github issues: this is the last assignee of an issue if
the issue has multiple assignees</li><li>For Jira issues: this is the assignee
of the issue at the time of collection</li></ul>
[...]
+| `original_estimate_minutes` | int | | The original
estimation of the time allocated for this issue
[...]
+| `time_spent_minutes` | int | | The original
estimation of the time allocated for this issue
[...]
+| `time_remaining_minutes` | int | | The remaining time to
resolve the issue
[...]
+| `creator_id` | varchar | 255 | The id of issue
creator
[...]
+| `creator_name` | varchar | 255 | The name of the
creator
[...]
+| `assignee_id` | varchar | 255 | The id of issue
assignee.<ul><li>For Github issues: this is the last assignee of an issue if
the issue has multiple assignees</li><li>For Jira issues: this is the assignee
of the issue at the time of collection</li></ul>
[...]
| `assignee_name` | varchar | 255 | The name of the
assignee
[...]
| `created_date` | datetime | 3 | The time issue created
[...]
| `updated_date` | datetime | 3 | The last time issue
gets updated
[...]
| `resolution_date` | datetime | 3 | The time the issue
changes to 'DONE'.
[...]
-| `lead_time_minutes` | int | | Describes the cycle
time from issue creation to issue resolution.<ul><li>For issues whose type =
'REQUIREMENT' and status = 'DONE', lead_time_minutes = resolution_date -
created_date. The unit is minute.</li><li>For issues whose type !=
'REQUIREMENT' or status != 'DONE', lead_time_minutes is null</li></ul>
[...]
+| `lead_time_minutes` | int | | Describes the cycle
time from issue creation to issue resolution.<ul><li>For issues whose type =
'REQUIREMENT' and status = 'DONE', lead_time_minutes = resolution_date -
created_date. The unit is minute.</li><li>For issues whose type !=
'REQUIREMENT' or status != 'DONE', lead_time_minutes is null</li></ul>
[...]
#### issue_labels
@@ -143,20 +143,20 @@ This table shows the changelogs of issues. Issues with
multiple changelogs are s
This table shows the work logged under issues. Usually, an issue has multiple
worklogs logged by different developers.
-| **field** | **type** | **length** | **description**
| **key**
|
-| :------------------- | :------- | :--------- |
:-------------------------------------------------------------------------------------------
| :--------------- |
-| `id` | varchar | 255 | The id of the worklog
|
PK |
-| `author_id` | varchar | 255 | The id of the author who
logged the work |
FK_acccounts.id |
-| `comment` | longtext | 255 | The comment made while
logging the work. |
|
-| `time_spent_minutes` | int | | The time logged. The unit of
value is normalized to minute. Eg. 1d =) 480, 4h30m =) 270 |
|
-| `logged_date` | datetime | 3 | The time of this logging
action |
|
-| `started_date` | datetime | 3 | Start time of the worklog
|
|
-| `issue_id` | varchar | 255 | Issue ID
| FK_issues.id
|
+| **field** | **type** | **length** | **description**
| **key**
|
+| :------------------- | :------- | :--------- |
:-------------------------------------------------------------------------------------------
|:----------------|
+| `id` | varchar | 255 | The id of the worklog
|
PK |
+| `author_id` | varchar | 255 | The id of the author who
logged the work |
FK_accounts.id |
+| `comment` | longtext | 255 | The comment made while
logging the work. |
|
+| `time_spent_minutes` | int | | The time logged. The unit of
value is normalized to minute. Eg. 1d =) 480, 4h30m =) 270 |
|
+| `logged_date` | datetime | 3 | The time of this logging
action |
|
+| `started_date` | datetime | 3 | Start time of the worklog
|
|
+| `issue_id` | varchar | 255 | Issue ID
| FK_issues.id
|
#### boards
-A `board` is an issue list or a collection of issues. It's the abstraction of
a Jira board, a Jira project, a [Github issue
list](https://github.com/merico-dev/lake/issues) or a GitLab issue list. This
table can be used to filter issues by the boards they belong to.
+A `board` is an issue list or a collection of issues. It's the abstraction of
a Jira board, a Jira project, a [GitHub issue
list](https://github.com/merico-dev/lake/issues) or a GitLab issue list. This
table can be used to filter issues by the boards they belong to.
| **field** | **type** | **length** | **description**
| **key** |
| :------------- | :------- | :--------- |
:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| :------ |
@@ -178,18 +178,18 @@ This table shows the relation between boards and issues.
This table can be used
#### sprints
-A `sprint` is the abstraction of Jira sprints, TAPD iterations and Github
milestones. A sprint contains a list of issues.
+A `sprint` is the abstraction of Jira sprints, TAPD iterations and GitHub
milestones. A sprint contains a list of issues.
-| **field** | **type** | **length** | **description**
[...]
-| :------------------ | :------- | :--------- |
:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
-| `id` | varchar | 255 | A sprint's `id` is composed of
"< plugin >:< Entity >:< PK0 >[:PK1]..."<ul><li>A sprint in a Github repo is a
milestone, the sprint id is like "< github >:< GithubRepos >:< GithubRepoId >:<
milestoneNumber >".<br/>Eg. The id for this
[sprint](https://github.com/merico-dev/lake/milestone/5) is
"github:GithubRepo:384111310:5"</li><li>For a Jira Board, the id is like "<
jira >:< JiraSourceId >< JiraBoards >:< JiraBoardsId >".<br/>Eg. "jira:1:J [...]
-| `name` | varchar | 255 | The name of sprint.<br/>For
Github projects, the sprint name is the milestone name. For instance, 'v0.10.0
- Introduce Temporal to DevLake' is the name of this
[sprint](https://github.com/merico-dev/lake/milestone/5).
[...]
-| `url` | varchar | 255 | The url of sprint.
[...]
-| `status` | varchar | 255 | There're 3 statuses of a
sprint:<ul><li>CLOSED: a completed sprint</li><li>ACTIVE: a sprint started but
not completed</li><li>FUTURE: a sprint that has not started</li></ul>
[...]
-| `started_date` | datetime | 3 | The start time of a sprint
[...]
-| `ended_date` | datetime | 3 | The planned/estimated end time
of a sprint. It's usually set when planning a sprint.
[...]
-| `completed_date` | datetime | 3 | The actual time to complete a
sprint.
[...]
-| `original_board_id` | datetime | 3 | The id of board where the
sprint first created. This field is not null only when this entity is
transformed from Jira sprintas.<br/>In Jira, sprint and board entities have 2
types of relation:<ul><li>A sprint is created based on a specific board. In
this case, board(1):(n)sprint. The `original_board_id` is used to show the
relation.</li><li>A sprint can be mapped to multiple boards, a board can also
show multiple sprints. In this case, boar [...]
+| **field** | **type** | **length** | **description**
[...]
+| :------------------ | :------- | :---------
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
+| `id` | varchar | 255 | A sprint's `id` is composed of
"< plugin >:< Entity >:< PK0 >[:PK1]..."<ul><li>A sprint in a Github repo is a
milestone, the sprint id is like "< github >:< GithubRepos >:< GithubRepoId >:<
milestoneNumber >".<br/>Eg. The id for this
[sprint](https://github.com/merico-dev/lake/milestone/5) is
"github:GithubRepo:384111310:5"</li><li>For a Jira Board, the id is like "<
jira >:< JiraSourceId >< JiraBoards >:< JiraBoardsId >".<br/>Eg. "jira:1:J [...]
+| `name` | varchar | 255 | The name of sprint.<br/>For
Github projects, the sprint name is the milestone name. For instance, 'v0.10.0
- Introduce Temporal to DevLake' is the name of this
[sprint](https://github.com/merico-dev/lake/milestone/5).
[...]
+| `url` | varchar | 255 | The url of sprint.
[...]
+| `status` | varchar | 255 | There're 3 statuses of a
sprint:<ul><li>CLOSED: a completed sprint</li><li>ACTIVE: a sprint started but
not completed</li><li>FUTURE: a sprint that has not started</li></ul>
[...]
+| `started_date` | datetime | 3 | The start time of a sprint
[...]
+| `ended_date` | datetime | 3 | The planned/estimated end time
of a sprint. It's usually set when planning a sprint.
[...]
+| `completed_date` | datetime | 3 | The actual time to complete a
sprint.
[...]
+| `original_board_id` | datetime | 3 | The id of board where the
sprint first created. This field is not null only when this entity is
transformed from Jira sprints.<br/>In Jira, sprint and board entities have 2
types of relation:<ul><li>A sprint is created based on a specific board. In
this case, board(1):(n)sprint. The `original_board_id` is used to show the
relation.</li><li>A sprint can be mapped to multiple boards, a board can also
show multiple sprints. In this case, board [...]
#### sprint_issues
@@ -218,7 +218,7 @@ This table shows the relation between sprints and issues
that have been added to
#### repos
-Information about Github or Gitlab repositories. A repository is always owned
by a user.
+Information about GitHub or Gitlab repositories. A repository is always owned
by a user.
| **field** | **type** | **length** | **description**
|
**key** |
| :------------- | :------- | :--------- |
:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| :---------- |
@@ -235,7 +235,7 @@ Information about Github or Gitlab repositories. A
repository is always owned by
#### repo_languages(WIP)
-Languages that are used in the repository along with byte counts for all files
in those languages. This is in line with how Github calculates language
percentages in a repository. Multiple entries can exist per repo.
+Languages that are used in the repository along with byte counts for all files
in those languages. This is in line with how GitHub calculates language
percentages in a repository. Multiple entries can exist per repo.
The table is filled in when the repo has been first inserted on when an update
round for all repos is made.
@@ -348,7 +348,7 @@ The parent commit(s) for each commit, as specified by Git.
#### pull_requests
-A pull request is the abstraction of Github pull request and Gitlab merge
request.
+A pull request is the abstraction of GitHub pull request and Gitlab merge
request.
| **field** | **type** | **length** | **description**
| **key** |
| :----------------- | :------- | :--------- |
:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| :------------- |
diff --git a/docs/DeveloperManuals/Dal.md b/docs/DeveloperManuals/Dal.md
index 9b085425a..3e1d397e5 100644
--- a/docs/DeveloperManuals/Dal.md
+++ b/docs/DeveloperManuals/Dal.md
@@ -76,7 +76,7 @@ err := db.Exec("UPDATE users SET department = ? WHERE
department = ?", "Research
### Insert
```go
err := db.Create(&models.User{
- Email: "[email protected]", // assumming this the Primarykey
+ Email: "[email protected]", // assuming this the Primarykey
Name: "hello",
Department: "R&D",
})
@@ -85,7 +85,7 @@ err := db.Create(&models.User{
### Update
```go
err := db.Create(&models.User{
- Email: "[email protected]", // assumming this the Primarykey
+ Email: "[email protected]", // assuming this the Primarykey
Name: "hello",
Department: "R&D",
})
diff --git a/docs/DeveloperManuals/E2E-Test-Guide.md
b/docs/DeveloperManuals/E2E-Test-Guide.md
index 9e28fef12..1156e4cd2 100644
--- a/docs/DeveloperManuals/E2E-Test-Guide.md
+++ b/docs/DeveloperManuals/E2E-Test-Guide.md
@@ -81,7 +81,7 @@ However, it is obvious that the escape symbol does not
conform to the csv specif
The data field of this file is encoded in base64, so it needs to be decoded
manually to a literal amount before using it.
-### MySQL workerbench
+### MySQL workbench
This tool must write the SQL yourself to complete the data export, which can
be rewritten by imitating the following SQL.
```sql
@@ -183,13 +183,12 @@
dataflowTester.VerifyTableWithOptions(models.FeishuMeetingTopUserItem{},
)
```
-The above usage will default to validating against all fields of the
```models.FeishuMeetingTopUserItem``` model. There are additional fields on
```TableOptions``` that can be specified
-to limit which fields on that model to perform validation on.
+The above usage will be default to validating against all fields of the
`models.FeishuMeetingTopUserItem` model. There are additional fields on
`TableOptions` that can be specified to limit which fields on that model to
perform validation on.
To facilitate the generation of the file mentioned above, DevLake has adopted
a testing technique called `Snapshot`, which will automatically generate the
file based on the run results when the `VerifyTable` or
`VerifyTableWithOptions` functions are called without the csv existing.
But note! Please do two things after the snapshot is created: 1. check if the
file is generated correctly 2. re-run it to make sure there are no errors
between the generated results and the re-run results.
-These two operations are critical and directly related to the quality of test
writing. We should treat the snapshot file in `.csv' format like a code file.
+These two operations are critical and directly related to the quality of test
writing. We should treat the snapshot file in `.csv` format like a code file.
If there is a problem with this step, there are usually 2 ways to solve it.
1. The validated fields contain fields like create_at runtime or
self-incrementing ids, which cannot be repeatedly validated and should be
excluded.
diff --git a/docs/DeveloperManuals/PluginImplementation.md
b/docs/DeveloperManuals/PluginImplementation.md
index bcc6599fc..1be37bef1 100644
--- a/docs/DeveloperManuals/PluginImplementation.md
+++ b/docs/DeveloperManuals/PluginImplementation.md
@@ -66,7 +66,7 @@ flowchart TD;
end
S1-->S2-->S3-->S4
```
-There's a lot of information in the diagram but we don't expect you to digest
it right away, simply use it as a reference when you go through the example
below.
+There's a lot of information in the diagram, but we don't expect you to digest
it right away. You can simply use it as a reference when you go through the
example below.
## A step-by-step guide towards your first plugin
@@ -180,7 +180,7 @@ ResponseParser: func(res *http.Response)
([]json.RawMessage, error) {
},
```
-Ok, run the function `main` once again, then it turned out like this, and we
should be able see some records show up in the table `_raw_icla_committer`.
+Ok, run the function `main` once again, then it turned out like this, and we
should be able to see some records show up in the table `_raw_icla_committer`.
```bash
……
receive data: 272956 /* <- the number means 272956 models received */
diff --git a/docs/DeveloperManuals/TagNamingConventions.md
b/docs/DeveloperManuals/TagNamingConventions.md
index 7195070f6..3417c29b6 100644
--- a/docs/DeveloperManuals/TagNamingConventions.md
+++ b/docs/DeveloperManuals/TagNamingConventions.md
@@ -7,7 +7,7 @@ sidebar_position: 6
Please refer to the rules when creating a new tag for Apache DevLake
- alpha: internal testing/preview, i.e. v0.12.0-alpha1
-- beta: communtity/customer testing/preview, i.e. v0.12.0-beta1
+- beta: community/customer testing/preview, i.e. v0.12.0-beta1
- rc: asf release candidate, i.e. v0.12.0-rc1
diff --git a/docs/GettingStarted/RainbondSetup.md
b/docs/GettingStarted/RainbondSetup.md
index 40cf2fe70..41b3c1545 100644
--- a/docs/GettingStarted/RainbondSetup.md
+++ b/docs/GettingStarted/RainbondSetup.md
@@ -19,10 +19,10 @@ Install DevLake in Rainbond is the easiest way to get
started.
-2.fill in the install information, and click `Confirm` button startup install.
+2.fill in the installation information, and click `Confirm` button startup
install.
* Team: select a team or create a new team
* Cluster: select a cluster
- * Application: select a application or create a new application
+ * Application: select an application or create a new application
* Version: select a version
3.Moment later, DevLake will be installed successfully, via the `Access`
button to access DevLake.
