Welcome, and thank you for considering to contribute to OCM-Common. Before you begin, or have more questions reach out to us on Slack
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 dependenciesci
: Changes to our CI configuration files and scriptsdocs
: Documentation only changesperf
: A code change that improves performancerefactor
: A code change that neither fixes a bug nor adds a featurestyle
: 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 sprintIn Progress
ticket is currently being worked onCode Review
PR has been created and is being reviewed by the team.Review
Once the changes have been merged, move ticket toReview
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.
This repository uses GitHub actions which are configured at ./github/workflows
Releases are handled via GitHub action and goreleaser. Simply push a version tag to create a release.
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.
If you have any questions about the code or how to contribute, don't hesitate to open an issue in this repo