Skip to content

Latest commit

 

History

History
153 lines (118 loc) · 6.76 KB

CONTRIBUTING.md

File metadata and controls

153 lines (118 loc) · 6.76 KB
Raw

Contributing to the Conjur OSS Suite

Table of Contents

Prerequisites

Go version

To work in this codebase, you will want to have at least Go v1.13 installed. The code may work on older versions but it has not been tested nor evaluated to be compatible for those configurations. We expect at the very least that you will need Go modules support so you will at minimum need Go v1.11+.

Pull Request Workflow

  1. Search the open issues in GitHub to find out what has been planned
  2. Select an existing issue or open an issue to propose changes or fixes
  3. Add the implementing label to the issue as you begin to work on it
  4. Run tests as described here, ensuring they pass
  5. Submit a pull request, linking the issue in the description (e.g. Connected to #123)
  6. Add the implemented label to the issue, and ask another contributor to review and merge your code

Style guide

Use this guide to maintain consistent style across the project.

Building

Clone https://github.com/cyberark/conjur-oss-suite-release. If you are new to Go, be aware that Go can be very selective about where the files are placed on the filesystem. There is an environment variable called GOPATH, whose default value is ~/go. Conjur OSS Suite uses go modules which require either that you clone this repository outside of your GOPATH or you set the GO111MODULE environment variable to on. We recommend cloning this repository outside of your GOPATH.

Once you've cloned the repository, you can build and/or run the included code.

Running

Currently the only functionality included is the CHANGELOG.md generation which can be done with:

$ ./parse-changelog

Testing

Prerequisites

  • Docker

Running all tests

$ go test -v ./...

Running only unit (short) tests

$ go test -v -short ./...

Releasing

  1. Determine whether there are component changes since the last suite release that merit a new suite release.

    • Check the wiki to see the daily report on which components have had new tagged versions since the last release, and which components have unreleased changes.

      • Note: Entries for components with unreleased changes (changes on the master branch that are not yet available in a GitHub release) show in this report as org/repo @HEAD. The links take you to the commit history for all commits on master that are not included in the latest GitHub release.

    • If there are any components with unreleased changes that should be tagged, open an issue in that component's repository for adding a new tag.

  2. Ensure the components have green builds.

    • Check the Jenkins dashboard to make sure there are no ongoing build failures for any of the OSS suite components.

      Note: The Jenkins dashboard does not include the following components at this time:

  3. Update the versions included in the suite release.

    • Edit the suite release config to bump the versions of any components with new tags and/or to add any new components to the next suite release.

    • Submit your changes in a pull request (PR) as per our contributor guidelines.

      • Important: the PR description must include the suite release version (following semantic versioning of the new suite. The maintainers of this project will use this info to complete the release.
      • The PR to modify the suite.yml will automatically kick off the end-to-end tests for the suite against the pinned suite component versions. If the tests don't pass, they'll need to be fixed before the new suite release can be created.
      • To see the status of the automated tests, you can check the status tab in the pull request.

    • A maintainer of this project will review the PR to make sure the release is ready to move forward. In particular, they will do the following before approving and merging the PR:

      • Check that the PR description includes the desired suite release version.
      • Review the status of the automated tests, to make sure they are passing.
      • Check the Jenkins dashboard to make sure there are no ongoing build failures for any of the OSS suite components.

    • Once the changes to update the suite are approved and merged to master, the maintainer will create a new git tag. Creating a git tag (as outlined in the maintainer docs):

      • Re-runs the automated end-to-end tests against the current pinned versions in suite.yml
      • Auto-generates HTML release notes for the docs website
      • Auto-generates a draft GitHub release; that is, the automated process:
        • Creates the suite CHANGELOG.md
        • Creates GitHub release notes
        • Creates draft GitHub release populated with release notes and with attached artifacts, including CHANGELOG.md, suite.yml, HTML release notes, etc
      • Note: To view the progress of the GitHub actions that automatically run post-tag, you can take a look at this page.

  4. Publish the draft GitHub release. If additional validation is needed, it can be initially published as a pre-release and promoted to a full release once final validation is complete.

    Publishing the release:

    • Runs the end-to-end test suite again
    • Archives the current suite.yml as releases/suite-x.y.z.yml where x.y.z is the new suite release version.
    • Manual publishing of the release will make it public for consumers of this repo.