Skip to content

Latest commit

 

History

History
127 lines (90 loc) · 6.32 KB

CONTRIBUTING.md

File metadata and controls

127 lines (90 loc) · 6.32 KB
Raw

Contributing

For general information about the acceptance criteria for a community contribution, please make sure to visit our doc page before you start your very much appreciated work!

GitHub Flow

For more information see GitHub Flow

GitHub Flow is very lightweight (especially compared to GitFlow). This workflow uses only two kinds of branches:

  • Feature branch
  • Main branch (previously called master)

The feature branches are used to develop new features as well as fixes. These branches are usually created out of main.

Anything in the main branch is deployable. The main branch is expected to be deployed regularly and is considered stable.

How to work with GitHub Flow

For more information see GitHub Flow

TL;DR

  1. anything in the main branch is deployable
  2. create descriptive branches off of main
  3. push to named branches constantly
  4. open a pull request at any time
  5. merge only after pull request review
  6. deploy immediately after review

Working with Forks and Pull Requests

If you want to contribute you will need to fork the project. To enable the use of our CI Pipeline you will need to add these GitHub secrets:

Secret Usage
DOCKER_NAMESPACE This is the namespace for the docker images. For the main repository this is securecodebox. On you fork this is probably your Docker user
DOCKER_USERNAME This is the username that is used to push the Docker images
DOCKER_TOKEN This is the Token that enables the CI to push

If you want early feedback feel free to open a Draft Pull Request. When you are done, you can convert it to a standard Pull Request (or create one if you did not create a Draft Pull Request).

Generally the secureCodeBox project follows the standard GitHub Pull request process.

Bugfixing and Security Fixing Released Features

For bugfixes and security fixes of the current release please follow the following workflow:

  • For the minor release
    • Checkout current minor release branch (e.g. v2.5.x) or create if not existent from latest git tag
    • Create a bugfix branch from release branch
    • Fix Bug
    • Create PR to release branch
    • Generate new semver release
  • For the main branch:
    • Create a bugfix branch from main branch
    • Cherry-Pick Bugfix and commit to bugfix branch
    • Create PR to main branch

Working with Issues - How to Contribute in Issues

It is mandatory to open an issue, if the task takes longer than one hour. Before you open an issue please verify there is no existing one covering your issue.

How to Write Commit Messages

For more information see Chris Beams article.

TL;DR

  1. Separate subject from body with a blank line.
  2. Add the issue number at beginning of to the subject line (e.g. "#42 Add the Answer to the Live, Universe, and the Rest")
  3. Limit the subject line to 50 characters.
  4. Capitalize the subject line.
  5. Do not end the subject line with a period.
  6. Use the imperative mood in the subject line.
  7. Wrap the body at 72 characters.
  8. Use the body to explain what and why (not how because this is obvious from the diff).

NOTE: Make sure you don't include @mentions or fixes keywords in your git commit messages. These should be included in the PR body instead.

NOTE: Make sure to add your signed-off-by tag as described in our contributors file.

Code of Conduct

Please have a look at our Code of Conduct before you write an Issue or make a PR.

Developer Certificate of Origin and Licensing

We decided to use DCO instead of CLA as described in CLAs and using DCO clearly. The reason for that: We need to be sure that one submitting a contribution to this repository is allowed to do this and does not violates copyrights of someone else. For that purpose you have to do some steps to to fullfil our DCO requirements:

  1. Read carefully our contributors file.
  2. Open a pull request which adds you to the contributors file to agree the DCO.
  3. Always add a signed-off tag to all your commits as described in the contributors file.
  4. Add a SPDX license header to all files your contribution will create. You can use the reuse tool with our helper script.

Verified commits

It is also a good idea to always cryptographically sign all of your commits (See: git-scm). You can check if your commits were successfully signed by looking for the Verified tag on your commits on GitHub. This is optional for community contributions, but strongly encouraged.