github.com/quay/claircore@v1.5.28/docs/CONTRIBUTING.md (about)

     1  # How to contribute
     2  
     3  The preferred workflow is to fork the `quay/claircore` repository, push a feature branch to the new fork, then open a pull request.
     4  All pull requests should be targeted to the `main` branch outside of exceptional circumstances.
     5  
     6  ## Testing
     7  
     8  As many tests as possible should run with the standard `go test` invocations.
     9  Adding the special tag `integration` (e.g. `go test -tags integration ./...`) will also run "integration" tests.
    10  The project interprets "integration" tests to mean any test that would need external resources, such as:
    11  
    12  - External web servers
    13  - External network access
    14  - Out-of-process databases
    15  - Large test fixtures
    16  
    17  After at least one run with the `integration` tag, the tests should cache needed resources and run as many tests as possible.
    18  See also the [`test/integration`][doc-integration] package.
    19  
    20  ## Pull Requests
    21  
    22  The Pull Request (PR) is the unit of code review.
    23  Claircore's review flow treats a feature branch as a stack of patches to be applied.
    24  That is to say, the feature branch should be rebased onto the target branch and have well-organized commits.
    25  Merge commits are disallowed.
    26  If the author would prefer to not rewrite commit history while working through reviews, [fixup commits] are the suggested way to achieve that.
    27  As many requirements as possible are enforced by CI, like:
    28  
    29  - Commits being signed off
    30  - Commit messages having a properly formed subject
    31  - Go modules being tidied
    32  
    33  Please use the "draft" option if the branch is not ready.
    34  Please enable the "allow edits by maintainers" option.
    35  
    36  The maintainers may rebase, push, and merge contributors' branches.
    37  This may necessitate doing a `git reset <remote>/<branch>` to update a local branch.
    38  
    39  ## Conventions
    40  
    41  Git commits should be formatted like "subject: summary" and avoid going over 80 characters per line.
    42  The "subject" is usually the package affected by the commit (like `jar` or `rhel` -- the relative path isn't needed) but sometimes a broader category (like `docs`, `all`, or `cicd`) is OK.
    43  
    44  All the helper scripts should handle the "normal" convention (`origin` is `quay/claircore` and `fork` is one's personal fork) and the "British" convention (`origin` is one's personal fork and `upstream` is `quay/claircore`).
    45  
    46  More detailed contributor documentation can be found in [the project documentation][docs].
    47  
    48  [doc-integration]: https://pkg.go.dev/github.com/quay/claircore/test/integration
    49  [fixup commits]: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt
    50  [docs]: https://quay.github.io/claircore/contributor.html