Skip to content

Latest commit

 

History

History
101 lines (77 loc) · 4.65 KB

CONTRIBUTING.md

File metadata and controls

101 lines (77 loc) · 4.65 KB

Contributing

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

Table of Contents

Development

This project requires only Docker for all testing and generation scripts. If you want to run the integration tests locally you will need Java 15 and Maven installed.

Refreshing the client

Each time there is an update to the OpenAPI Specification the client will need to be "refreshed" and released. This can be done by running the bin/refresh_client script, the commit message Client refresh is adequate. Make sure to follow the steps laid out in the releases section when releasing the client after a refresh.

Utility Scripts

bin/test_integration

  • Used to run the suite of integration tests against a Conjur instance.
  • Stands up a new instance of Conjur in a Docker environment, compiles the client, and runs the tests with Maven.

bin/build

  • Used to compile & build a jar archive for the client.
  • Outputs the compiled version to client/target

bin/refresh_client

  • Used to update the client with new changes to the OpenAPI Specification.
  • Pulls down the latest version of the spec and regenerates the client.
  • Only certain files will be updated, see client/.openapi-generator-ignore for ignored files.

bin/start_conjur

  • Used to start a new local Conjur instance based on the project's docker-compose.yml file.

bin/lint

Testing

To run the integration tests use the bin/test_integration script. This will bring up an instance of Conjur, compile the client and run the tests via Maven.

Releases

A new release must be created whenever a new version of the OpenAPI Specification is released.

Update the version and changelog

  1. Examine the changelog and decide on the version bump rank (major, minor, patch).
  2. Change the title of Unreleased section of the changelog to the target version.
    • Be sure to add the date (ISO 8601 format) to the section header.
  3. Add a new, empty Unreleased section to the changelog.
    • Remember to update the references at the bottom of the document.
  4. Update the README Version chart to reflect compatability with the new release version.
  5. Update the version in the client/pom.xml and templates/libraries/okhttp-gson/pom.mustache files.
  6. Commit these changes (including the changes to NOTICES.txt, if there are any). Bump version to x.y.z is an acceptable commit message.
  7. Push your changes to a branch, and get the PR reviewed and merged.

Tag the version

  1. Tag the version on the master branch using eg. git tag -s vx.y.z -m vx.y.z. Note this requires you to be able to sign releases. Consult the github documentation on signing commits on how to set this up.

  2. Push the tag: git push vx.y.z (or git push origin vx.y.z if you are working from your local machine).

Add a new GitHub release

  1. Create a new release from the tag in the GitHub UI
  2. Add the CHANGELOG for the current version to the GitHub release description

Contributing 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!