Skip to content

Commit b4a7d6a

Browse files
authored
docs: move CONTRIBUTING.md to docs (#1971)
1 parent 0127c1d commit b4a7d6a

File tree

6 files changed

+111
-106
lines changed

6 files changed

+111
-106
lines changed

CONTRIBUTING.md

Lines changed: 1 addition & 104 deletions
Original file line numberDiff line numberDiff line change
@@ -1,104 +1 @@
1-
Thank you for taking interest in contributing to Trivy!
2-
3-
## Issues
4-
- Feel free to open issues for any reason. When you open a new issue, you'll have to select an issue kind: bug/feature/support and fill the required information based on the selected template.
5-
- Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate. If it is, please add your comment to the existing issue.
6-
- Remember that users might search for your issue in the future, so please give it a meaningful title to help others.
7-
- The issue should clearly explain the reason for opening, the proposal if you have any, and any relevant technical information.
8-
9-
## Pull Requests
10-
11-
1. Every Pull Request should have an associated bug or feature issue unless you are fixing a trivial documentation issue.
12-
4. Please add the associated Issue link in the PR description.
13-
2. Your PR is more likely to be accepted if it focuses on just one change.
14-
5. There's no need to add or tag reviewers.
15-
6. If a reviewer commented on your code or asked for changes, please remember to respond with comment. Do not mark discussion as resolved. It's up to reviewer to mark it resolved (in case if suggested fix addresses problem properly). PRs with unresolved issues should not be merged (even if the comment is unclear or requires no action from your side).
16-
7. Please include a comment with the results before and after your change.
17-
8. Your PR is more likely to be accepted if it includes tests (We have not historically been very strict about tests, but we would like to improve this!).
18-
9. If your PR affects the user experience in some way, please update the README.md and the CLI help accordingly.
19-
20-
### Title
21-
It is not that strict, but we use the title conventions in this repository.
22-
Each commit message doesn't have to follow the conventions as long as it is clear and descriptive since it will be squashed and merged.
23-
24-
#### Format of the title
25-
26-
```
27-
<type>(<scope>): <subject>
28-
```
29-
30-
The `type` and `scope` should always be lowercase as shown below.
31-
32-
**Allowed `<type>` values:**
33-
- **feat** for a new feature for the user, not a new feature for build script. Such commit will trigger a release bumping a MINOR version.
34-
- **fix** for a bug fix for the user, not a fix to a build script. Such commit will trigger a release bumping a PATCH version.
35-
- **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version.
36-
- **docs** for changes to the documentation.
37-
- **style** for formatting changes, missing semicolons, etc.
38-
- **refactor** for refactoring production code, e.g. renaming a variable.
39-
- **test** for adding missing tests, refactoring tests; no production code change.
40-
- **build** for updating build configuration, development tools or other changes irrelevant to the user.
41-
- **chore** for updates that do not apply to the above, such as dependency updates.
42-
43-
**Example `<scope>` values:**
44-
- alpine
45-
- redhat
46-
- ruby
47-
- python
48-
- terraform
49-
- report
50-
- etc.
51-
52-
The `<scope>` can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.
53-
54-
#### Example titles
55-
56-
```
57-
feat(alma): add support for AlmaLinux
58-
```
59-
60-
```
61-
fix(oracle): handle advisories with ksplice versions
62-
```
63-
64-
```
65-
docs(misconf): add comparison with Conftest and TFsec
66-
```
67-
68-
```
69-
chore(deps): bump go.uber.org/zap from 1.19.1 to 1.20.0
70-
```
71-
72-
**NOTE**: please do not use `chore(deps): update fanal` and something like that if you add new features or fix bugs in Trivy-related projects.
73-
The PR title should describe what the PR adds or fixes even though it just updates the dependency in Trivy.
74-
75-
### Unit tests
76-
Your PR must pass all the unit tests. You can test it as below.
77-
78-
```
79-
$ make test
80-
```
81-
82-
### Integration tests
83-
Your PR must pass all the integration tests. You can test it as below.
84-
85-
```
86-
$ make test-integration
87-
```
88-
89-
### Documentation
90-
You can build the documents as below and view it at http://localhost:8000.
91-
92-
```
93-
$ make mkdocs-serve
94-
```
95-
96-
## Understand where your pull request belongs
97-
98-
Trivy is composed of several different repositories that work together:
99-
100-
- [Trivy](https://github.com/aquasecurity/trivy) is the client-side, user-facing, command line tool.
101-
- [vuln-list](https://github.com/aquasecurity/vuln-list) is a vulnerabilities database, aggregated from different sources, and normalized for easy consumption. Think of this as the "server" side of the trivy command line tool. **There should be no pull requests to this repo**
102-
- [vuln-list-update](https://github.com/aquasecurity/vuln-list-update) is the code that maintains the vuln-list database.
103-
- [trivy-db](https://github.com/aquasecurity/trivy-db) maintains the vulnerability database pulled by Trivy CLI.
104-
- [fanal](https://github.com/aquasecurity/fanal) is a library for extracting system information from containers. It is being used by Trivy to find testable subjects in the container image.
1+
See [Issues](https://aquasecurity.github.io/trivy/latest/community/contribute/issue/) and [Pull Requests](https://aquasecurity.github.io/trivy/latest/community/contribute/pr/)

docs/community/contribute/issue.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
Thank you for taking interest in contributing to Trivy!
2+
3+
- Feel free to open issues for any reason. When you open a new issue, you'll have to select an issue kind: bug/feature/support and fill the required information based on the selected template.
4+
- Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate. If it is, please add your comment to the existing issue.
5+
- Remember that users might search for your issue in the future, so please give it a meaningful title to help others.
6+
- The issue should clearly explain the reason for opening, the proposal if you have any, and any relevant technical information.

docs/community/contribute/pr.md

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
Thank you for taking interest in contributing to Trivy!
2+
3+
1. Every Pull Request should have an associated bug or feature issue unless you are fixing a trivial documentation issue.
4+
1. Please add the associated Issue link in the PR description.
5+
1. Your PR is more likely to be accepted if it focuses on just one change.
6+
1. There's no need to add or tag reviewers.
7+
1. If a reviewer commented on your code or asked for changes, please remember to respond with comment. Do not mark discussion as resolved. It's up to reviewer to mark it resolved (in case if suggested fix addresses problem properly). PRs with unresolved issues should not be merged (even if the comment is unclear or requires no action from your side).
8+
1. Please include a comment with the results before and after your change.
9+
1. Your PR is more likely to be accepted if it includes tests (We have not historically been very strict about tests, but we would like to improve this!).
10+
1. If your PR affects the user experience in some way, please update the README.md and the CLI help accordingly.
11+
12+
### Title
13+
It is not that strict, but we use the title conventions in this repository.
14+
Each commit message doesn't have to follow the conventions as long as it is clear and descriptive since it will be squashed and merged.
15+
16+
#### Format of the title
17+
18+
```
19+
<type>(<scope>): <subject>
20+
```
21+
22+
The `type` and `scope` should always be lowercase as shown below.
23+
24+
**Allowed `<type>` values:**
25+
26+
- **feat** for a new feature for the user, not a new feature for build script. Such commit will trigger a release bumping a MINOR version.
27+
- **fix** for a bug fix for the user, not a fix to a build script. Such commit will trigger a release bumping a PATCH version.
28+
- **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version.
29+
- **docs** for changes to the documentation.
30+
- **style** for formatting changes, missing semicolons, etc.
31+
- **refactor** for refactoring production code, e.g. renaming a variable.
32+
- **test** for adding missing tests, refactoring tests; no production code change.
33+
- **build** for updating build configuration, development tools or other changes irrelevant to the user.
34+
- **chore** for updates that do not apply to the above, such as dependency updates.
35+
36+
**Example `<scope>` values:**
37+
38+
- alpine
39+
- redhat
40+
- ruby
41+
- python
42+
- terraform
43+
- report
44+
- etc.
45+
46+
The `<scope>` can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.
47+
48+
#### Example titles
49+
50+
```
51+
feat(alma): add support for AlmaLinux
52+
```
53+
54+
```
55+
fix(oracle): handle advisories with ksplice versions
56+
```
57+
58+
```
59+
docs(misconf): add comparison with Conftest and TFsec
60+
```
61+
62+
```
63+
chore(deps): bump go.uber.org/zap from 1.19.1 to 1.20.0
64+
```
65+
66+
**NOTE**: please do not use `chore(deps): update fanal` and something like that if you add new features or fix bugs in Trivy-related projects.
67+
The PR title should describe what the PR adds or fixes even though it just updates the dependency in Trivy.
68+
69+
### Unit tests
70+
Your PR must pass all the unit tests. You can test it as below.
71+
72+
```
73+
$ make test
74+
```
75+
76+
### Integration tests
77+
Your PR must pass all the integration tests. You can test it as below.
78+
79+
```
80+
$ make test-integration
81+
```
82+
83+
### Documentation
84+
You can build the documents as below and view it at http://localhost:8000.
85+
86+
```
87+
$ make mkdocs-serve
88+
```
89+
90+
## Understand where your pull request belongs
91+
92+
Trivy is composed of several repositories that work together:
93+
94+
- [Trivy](https://github.com/aquasecurity/trivy) is the client-side, user-facing, command line tool.
95+
- [vuln-list](https://github.com/aquasecurity/vuln-list) is a vulnerabilities database, aggregated from different sources, and normalized for easy consumption. Think of this as the "server" side of the trivy command line tool. **There should be no pull requests to this repo**
96+
- [vuln-list-update](https://github.com/aquasecurity/vuln-list-update) is the code that maintains the vuln-list database.
97+
- [trivy-db](https://github.com/aquasecurity/trivy-db) maintains the vulnerability database pulled by Trivy CLI.
98+
- [fanal](https://github.com/aquasecurity/fanal) is a library for extracting system information from containers. It is being used by Trivy to find testable subjects in the container image.
99+
- [go-dep-parser](https://github.com/aquasecurity/go-dep-parser) is a library for parsing lock files such as package-lock.json and Gemfile.lock.
File renamed without changes.

mkdocs.yml

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -105,9 +105,12 @@ nav:
105105
- References: community/references.md
106106
- CKS Reference: community/cks.md
107107
- Credits: community/credit.md
108+
- How to contribute:
109+
- Issues: community/contribute/issue.md
110+
- Pull Requests: community/contribute/pr.md
108111
- Maintainer:
109-
- Help Wanted: community/contrib/help-wanted.md
110-
- Triage: community/contrib/triage.md
112+
- Help Wanted: community/maintainer/help-wanted.md
113+
- Triage: community/maintainer/triage.md
111114
theme:
112115
name: material
113116
language: 'en'

0 commit comments

Comments
 (0)