Skip to content

Latest commit

 

History

History
78 lines (59 loc) · 3.62 KB

CONTRIBUTING.md

File metadata and controls

78 lines (59 loc) · 3.62 KB
Raw

Contributing

For general contribution and community guidelines, please see the community repo.

Prerequisites

  1. git to manage source code
  2. Docker to manage dependencies and runtime environments
  3. Go 1.22.1+ installed

Testing

This project includes table-driven unit tests for each component. To run them:

./bin/test_unit

This script generates a coverage profile in the test/ directory. To generate a more consumable HTML coverage profile:

go tool cover -html ./test/c.out -o ./test/c.html
open ./test/c.html

This project also includes end-to-end tests exercising core functionality. To run them:

./bin/test_e2e # KinD

./bin/test_e2e openshift {current-dev/oldest-dev/next-dev} # OpenShift

Pull Request Workflow

  1. Fork the project
  2. Clone your fork
  3. Make local changes to your fork by editing files
  4. Commit your changes
  5. Push your local changes to the remote server
  6. Create new Pull Request

From here your pull request will be reviewed and once you've responded to all feedback it will be merged into the project. Congratulations, you're a contributor!

Releases

Releases should be created by maintainers only. To create a tag and release, follow the instructions in this section.

Pre-requisites

  1. Review the git log and ensure the changelog contains all relevant recent changes with references to GitHub issues or PRs, if possible. Also ensure the latest unreleased version is accurate - our pipeline generates a VERSION file based on the changelog, which is then used to assign the version of the release and any release artifacts.
  2. Review the changes since the last tag, and if the dependencies have changed revise the NOTICES to correctly capture the included dependencies and their licenses / copyrights.
  3. Ensure that all documentation that needs to be written has been written by TW, approved by PO/Engineer, and pushed to the forward-facing documentation.
  4. Scan the project for vulnerabilities

Release and Promote

  1. Merging into main/master branches will automatically trigger a release. If successful, this release can be promoted at a later time.
  2. Jenkins build parameters can be utilized to promote a successful release or manually trigger aditional releases as needed.
  3. Reference the internal automated release doc for releasing and promoting.

Push Helm package

  1. Every release build packages the CSI Provider Helm chart for us. The package can be found on the draft (or published) release for the relevant version.
  2. Clone the repo helm-charts and do the following:
    1. Move the Helm package file created in the previous step to the docs folder in the helm-charts repo.
    2. Go to the helm-charts repo root folder and execute the reindex.sh script file located there.
    3. Create a PR with those changes.