Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
94 lines (65 loc) · 3.25 KB

CONTRIBUTING.md

File metadata and controls

94 lines (65 loc) · 3.25 KB

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 develop and run tests against Conjur OSS, use the start and stop scripts in the dev folder. The start script brings up a Conjur OSS (and Postgres database), CLI container, and a "work" container, with the gem code mounted into the working directory.

Starting a Shell

To begin:

$ cd dev
$ ./start
...
root@9df0ac10ada2:/src/conjur-api#

You'll be dropped into development container upon completion. From there, install the development gems:

root@9df0ac10ada2:/src/conjur-api# bundle

Running Tests

Tests can be run with:

root@9df0ac10ada2:/src/conjur-api# bundle exec cucumber features
root@9df0ac10ada2:/src/conjur-api# bundle exec rspec

Note: At the moment some of the cucumber tests are failing when run in the development container. You can use the CI script, test.sh to run the full test suite instead.

Stopping & Environment Cleanup

Once you're done, exit the shell, and stop the containers:

root@9df0ac10ada2:/src/conjur-api# exit
$ ./stop

Demos

bundle exec ./example/demo.rb <admin-api-key>

Stopping

To bring it down, run:

docker compose down

Releasing

Update the version and changelog

  1. Create a new branch for the version bump.

  2. Based on the changelog content, determine the new version number and update.

  3. Review the changelog to make sure all relevant changes since the last release have been captured. You may find it helpful to look at the list of commits since the last release.

    This is also a good time to make sure all entries conform to our changelog guidelines.

  4. Commit these changes - Bump version to x.y.z is an acceptable commit message - and open a PR for review. Your PR should include updates to CHANGELOG.md.

Release and Promote

  1. Jenkins build parameters can be utilized to release and promote successful builds.
  2. Merging into main/master branches will automatically trigger a release.
  3. Reference the internal automated release doc for releasing and promoting.