Skip to content

Latest commit

 

History

History
102 lines (75 loc) · 4.61 KB

CONTRIBUTING.md

File metadata and controls

102 lines (75 loc) · 4.61 KB
Raw

Contributing to OCM-Common

Welcome, and thank you for considering to contribute to OCM-Common. Before you begin, or have more questions reach out to us on Slack

Contributing Code

To contribute bug fixes or features to OCM-Common:

  • Communicate your intent.
  • Make your changes.
  • Test your changes.
  • Open a Pull Request (PR).

Communicate your intent in the form of a JIRA ticket on the OCM project.

Be sure to practice good git commit hygiene as you make your changes. All but the smallest changes should be broken up into a few commits that tell a story. Use your git commits to provide context for the folks who will review PR. We strive to follow conventional commits.

The commit message should follow this template:

<type>[JIRA-TICKET] | [TYPE]: <MESSAGE>

[optional BODY]

[optional FOOTER(s)]

The commit contains the following structural types, to communicate your intent:

  • fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
  • feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).

Types other than fix: and feat: are allowed:

  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts
  • docs: Documentation only changes
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

All code should be covered by tests. We use Ginkgo. Other third party testing packages will be rejected.

Once you made and tested your changes, create a pull request (PR). In the PR overview please link the jira ticket associated with your change. This should follow the format JIRA: OCM-xxxx. Note the key word JIRA, use of any other key word may result in the bot performing unwanted action to the ticket in JIRA. Please also include in the overview any additional information not in the JIRA that may help set context around your intent. Also include any extra validation steps which may help reviews to validate the changes.

We work on a Sprint basis, all changes should be tracked by a JIRA. When being worked on these changes should be added to the current SDA sprint. These sprints are denoted as SDA - Sprint xxx. The workflow should be as follows:

  • Todo will complete in this current sprint
  • In Progress ticket is currently being worked on
  • Code Review PR has been created and is being reviewed by the team.
  • Review Once the changes have been merged, move ticket to Review a QE person will be assigned to the ticket and tested.
  • Done Once QE are satisfied with the change and bugs have been fixed the QE person assigned to your ticket will mark it as done

During Review, remain assigned to the ticket, so that QE knows who to assign any follow-up bugs to during testing. You will also be asked to review test cases for this change. QE will supply you with a link to the test cases, if you approve the test cases add tc-approved label to the JIRA, if you need changes to the test cases work with QE in the JIRA comments to resolve these changes.

GitHub Workflows

This repository uses GitHub actions which are configured at ./github/workflows

Releasing a new OCM-Common Version

Releasing a new version requires submitting an MR for review/merge with an update to the Version constant in version.go. Additionally, update the CHANGES.md file to include the new version and describe all changes included.

Below is an example CHANGES.md update:

## 0.1.39 Jul 3 2023

- Bump github.com/onsi/ginkgo/v2 from 2.8.1 to 2.9.1
- Update CONTRIBUTING.md contribution instructions
- Added new unit test in sample_test.go

Submit an MR for review/merge with the CHANGES.md and version.go update.

Finally, create and submit a new tag with the new version following the below example:

git checkout main
git pull
git tag -a -m 'Release 0.1.39' v0.1.39
git push origin v0.1.39

Note that a repository administrator may need to push the tag to the repository due to access restrictions.

Questions?

If you have any questions about the code or how to contribute, don't hesitate to open an issue in this repo