github.com/devseccon/trivy@v0.47.1-0.20231123133102-bd902a0bd996/docs/community/contribute/pr.md (about)

     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  ## Development
    13  Install the necessary tools for development by following their respective installation instructions.
    14  
    15  - [Go](https://go.dev/doc/install)
    16  - [Mage](https://magefile.org/)
    17  
    18  ### Build
    19  After making changes to the Go source code, build the project with the following command:
    20  
    21  ```shell
    22  $ mage build
    23  $ ./trivy -h
    24  ```
    25  
    26  ### Lint
    27  You must pass the linter checks:
    28  
    29  ```shell
    30  $ mage lint:run
    31  ```
    32  
    33  Additionally, you need to have run `go mod tidy`, so execute the following command as well:
    34  
    35  ```shell
    36  $ mage tidy
    37  ```
    38  
    39  To autofix linters use the following command:
    40  ```shell
    41  $ mage lint:fix
    42  ```
    43  
    44  ### Unit tests
    45  Your PR must pass all the unit tests. You can test it as below.
    46  
    47  ```
    48  $ mage test:unit
    49  ```
    50  
    51  ### Integration tests
    52  Your PR must pass all the integration tests. You can test it as below.
    53  
    54  ```
    55  $ mage test:integration
    56  ```
    57  
    58  ### Documentation
    59  If you update CLI flags, you need to generate the CLI references.
    60  The test will fail if they are not up-to-date.
    61  
    62  ```shell
    63  $ mage docs:generate
    64  ```
    65  
    66  You can build the documents as below and view it at http://localhost:8000.
    67  
    68  ```
    69  $ mage docs:serve
    70  ```
    71  
    72  ## Title
    73  It is not that strict, but we use the title conventions in this repository.
    74  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.
    75  
    76  ### Format of the title
    77  
    78  ```
    79  <type>(<scope>): <subject>
    80  ```
    81  
    82  The `type` and `scope` should always be lowercase as shown below.
    83  
    84  **Allowed `<type>` values:**
    85  
    86  - **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.
    87  - **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.
    88  - **perf** for performance improvements. Such commit will trigger a release bumping a PATCH version.
    89  - **docs** for changes to the documentation.
    90  - **style** for formatting changes, missing semicolons, etc.
    91  - **refactor** for refactoring production code, e.g. renaming a variable.
    92  - **test** for adding missing tests, refactoring tests; no production code change.
    93  - **build** for updating build configuration, development tools or other changes irrelevant to the user.
    94  - **chore** for updates that do not apply to the above, such as dependency updates.
    95  - **ci** for changes to CI configuration files and scripts
    96  - **revert** for revert to a previous commit
    97  
    98  **Allowed `<scope>` values:**
    99  
   100  checks:
   101  
   102  - vuln
   103  - misconf
   104  - secret
   105  - license
   106  
   107  mode:
   108  
   109  - image
   110  - fs
   111  - repo
   112  - sbom
   113  - k8s
   114  - server
   115  - aws
   116  - vm
   117  
   118  os:
   119  
   120  - alpine
   121  - redhat
   122  - alma
   123  - rocky
   124  - mariner
   125  - oracle
   126  - debian
   127  - ubuntu
   128  - amazon
   129  - suse
   130  - photon
   131  - distroless
   132  
   133  language:
   134  
   135  - ruby
   136  - php
   137  - python
   138  - nodejs
   139  - rust
   140  - dotnet
   141  - java
   142  - go
   143  - elixir
   144  - dart
   145  
   146  vuln:
   147  
   148  - os
   149  - lang
   150  
   151  config:
   152  
   153  - kubernetes
   154  - dockerfile
   155  - terraform
   156  - cloudformation
   157  
   158  container
   159  
   160  - docker
   161  - podman
   162  - containerd
   163  - oci
   164  
   165  cli:
   166  
   167  - cli
   168  - flag
   169  
   170  SBOM:
   171  
   172  - cyclonedx
   173  - spdx
   174  - purl
   175  
   176  others:
   177  
   178  - helm
   179  - report
   180  - db
   181  - deps
   182  
   183  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.
   184  
   185  ### Example titles
   186  
   187  ```
   188  feat(alma): add support for AlmaLinux
   189  ```
   190  
   191  ```
   192  fix(oracle): handle advisories with ksplice versions
   193  ```
   194  
   195  ```
   196  docs(misconf): add comparison with Conftest and TFsec
   197  ```
   198  
   199  ```
   200  chore(deps): bump go.uber.org/zap from 1.19.1 to 1.20.0
   201  ```
   202  
   203  **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.
   204  The PR title should describe what the PR adds or fixes even though it just updates the dependency in Trivy.
   205  
   206  ## Commits
   207  
   208  
   209  ## Understand where your pull request belongs
   210  
   211  Trivy is composed of several repositories that work together:
   212  
   213  - [Trivy](https://github.com/devseccon/trivy) is the client-side, user-facing, command line tool.
   214  - [vuln-list](https://github.com/aquasecurity/vuln-list) is a vulnerability 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**
   215  - [vuln-list-update](https://github.com/aquasecurity/vuln-list-update) is the code that maintains the vuln-list database.
   216  - [trivy-db](https://github.com/aquasecurity/trivy-db) maintains the vulnerability database pulled by Trivy CLI.
   217  - [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.