Skip to content

Latest commit

 

History

History
91 lines (66 loc) · 4.59 KB

CONTRIBUTING.md

File metadata and controls

91 lines (66 loc) · 4.59 KB
Raw

How to contribute

Operator Marketplace is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on commit message formatting, instructions on how to set up a dev environment, and other resources to help get contributions into operator-marketplace.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.

Setting up a dev environment

  • Fork the repository on GitHub
  • Clone the forked repository in your go path.
  • Get access to an OpenShift cluster. The marketplace-operator is currently supported on OpenShift 4.0. You can find instructions on installing an OpenShift cluster here.
  • The Cluster-Version-Operator(CVO) manages the lifecycle of the marketplace-operator along with other internal OpenShift components. Before deleting the marketplace-operator deployment, instruct CVO to stop managing the marketplace-operator
$ oc patch clusterversion version --type=merge -p '{"spec": {"overrides":[{"kind": "Deployment", "name": "marketplace-operator", "namespace": "openshift-marketplace", "unmanaged": true, "group": "apps"}]}}'
  • Delete the marketplace-operator deployment
$ oc delete deployment marketplace-operator -n openshift-marketplace
  • Install Operator-SDK.
  • Compile the marketplace-operator and start the operator in your dev environment
$ operator-sdk up local --namespace=openshift-marketplace --kubeconfig=<path-to-kubeconfig-file>

Testing changes to RBAC policy

  • If there's any modification in existing RBAC policies, the modifications need to be tested using a separate deployment. Easiest way to do this is to build an image locally using this dockerfile, push the image to a registry, and replace the image here with the newly built image. The operator can then be redeployed with the new changes.
$ cd <path-to-operator-marketplace-repo>

$ operator-sdk build . --tag=<REGISTRYHOST>/<USERNAME>/marketplace-operator

$ docker push <REGISTRYHOST>/<USERNAME>/marketplace-operator 

$ sed -i -e 's?quay.io/openshift/origin-operator-marketplace:latest?<REGISTRYHOST>/<USERNAME>/marketplace-operator?g' deploy/operator.yaml

$ oc apply -f deploy/operator.yaml

Reporting bugs and creating issues

If any part of the operator-marketplace project has bugs or documentation mistakes, please let us know by opening an issue or a PR.

Contribution flow

This is an outline of what a contributor's workflow looks like:

  • Fork the repository on GitHub
  • Clone the forked repository in your go path.
  • Create a topic branch from where to base the contribution. This is usually master.
  • Make commits of logical units. A commit should typically add a feature or fix a bug, but never both at the same time. A PR should also have one single commit, i.e all the changes made should be consolidated into one single commit.
  • Make sure commit messages are in the proper format (see below).
  • Push changes in a topic branch to a personal fork of the repository.
  • To make sure that your topic branch is in sync with the remote master branch, follow a rebase workflow.
  • Submit a pull request to operator-framework/operator-marketplace.
  • The PR must receive one /lgtm and one /approve comments from the maintainers of the operator-marketplace project.

Thanks for contributing!

Format of the commit message

We follow a convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why.

bug 1683422: [csc] Make CLI output less verbose

- Fixes #116
- Removed TARGETNAMESPACE and PACKAGES fields from output
- Modified catalogsourceconfig.crd to remove fields from `additionalPrinterColumns`

The format can be described more formally as follows:

<subsystem>: <what changed>
<BLANK LINE>
<why this change was made>
<BLANK LINE>
<footer>

The first line is the subject and should be no longer than 50 characters, the second line is always blank, and other lines should be wrapped at 80 characters. This allows the message to be easier to read on GitHub as well as in various git tools.