Skip to content

Latest commit

 

History

History
86 lines (64 loc) · 3.42 KB

CONTRIBUTING.md

File metadata and controls

86 lines (64 loc) · 3.42 KB
Raw

Contributing

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

Contributing

  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!

Development

To start developing and testing using our development scripts , the following tools need to be installed:

  • Docker
  • docker-compose

Running tests

To run the test suite, run:

./bin/test.sh

This will spin up a containerized Conjur environment and build the test containers, and will run all tests.

To run the tests against a specific version of Golang, you can run the following:

./bin/test.sh 1.21

This will spin up a containerized Conjur environment and build the test containers, and will run the tests in a golang:1.21 container

Supported arguments are 1.21 and 1.22, with the default being 1.22 if no argument is given.

Setting up a development environment

To start a container with terminal access, and the necessary test running dependencies installed, run:

./bin/dev.sh

You can then run the following command from the container terminal to run all tests:

go test -coverprofile="output/c.out" -v ./... | tee output/junit.output;
exit_code=$?;
echo "Exit code: $exit_code"

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.