Skip to content

Latest commit

 

History

History
124 lines (91 loc) · 5 KB

CONTRIBUTING_CLA.md

File metadata and controls

124 lines (91 loc) · 5 KB
Raw

Contributing to image-registry-operator-api

We welcome contributions from the community and first want to thank you for taking the time to contribute!

Please familiarize yourself with the Code of Conduct before contributing.

Before you start working with image-registry-operator-api, please read and sign our Contributor License Agreement CLA. If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will prompt you to do so when you open a Pull Request. For any questions about the CLA process, please refer to our FAQ.

Ways to contribute

We welcome many different types of contributions and not all of them need a Pull request. Contributions may include:

  • New features and proposals
  • Documentation
  • Bug fixes
  • Issue Triage
  • Answering questions and giving feedback
  • Helping to onboard new contributors
  • Other related activities

Propose a Change

We suggest beginning by submitting an issue so any high level feedback can be addressed early, particularly if significant effort will be involved.

Please submit feature requests and bug reports by using GitHub issues and filling in the supplied template with as much detail as you can.

Before submitting an issue, please search through open ones to ensure others have not submitted something similar. If a similar issue exists, please add any additional information as a comment.

Getting started

The image-registry-operator-api project currently requires a ESXi cluster in vSphere 8 with Kubernetes.

What this means in functional terms is that you can manage workloads in a given Workload Namespace using a Kubernetes client connected directly to an embedded Kubernetes API Server running in the vSphere cluster. The image registry operator APIs currently allow you to monitor ClusterContentLibrary and ClusterContentLibraryItem objects that exist in the target cluster and ContentLibrary and ContentLibraryItem objects that exist in the target namespace. The support to be able to create and manage them will be added soon.

Testing sample code

Package envtest provides libraries for integration testing by starting a local control plane. Control plane binaries (etcd and kube-apiserver) are loaded by default from /usr/local/kubebuilder/bin. This can be overridden by setting the KUBEBUILDER_ASSETS environment variable, or by directly creating a control plane for the environment to use.

By building the list-ctrl target, the tools target gets built too and the kubebuilder tool binaries are downloaded to the tools/bin folder and the KUBEBUILDER_ASSETS points to the location where the binaries are downloaded.

Build and Test the sample code

make list-ctrl ./hack/samples/bin/list-ctrl

Development Flow

Before submitting a pull request, please make sure you verify the changes locally. The Makefile in this repository provides useful targets such as all, generate, lint and list-ctrl to make verification easier.

After adding or modifying the APIs build the generate target and verify the generated CRDs under config/crd/bases folder. Add or modify the sample controller to test the changes under hack/samples/controller folder and execute the binary to verify the changes.

Contribution Flow

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

  • Make a fork of the repository within your GitHub account
  • Create a topic branch in your fork from where you want to base your work
  • Make commits of logical units
  • Make sure your commit messages are with the proper format, quality and descriptiveness (see below)
  • Push your changes to the topic branch in your fork
  • Create a pull request containing that commit

We follow the GitHub workflow and you can find more details on the GitHub flow documentation.

Pull Request Checklist

Before submitting your pull request, we advise you to use the following:

  • Check if your code changes will pass both code linting checks and unit tests.
  • Ensure your commit messages are descriptive. We follow the conventions on How to Write a Git Commit Message. Be sure to include any related GitHub issue references in the commit message. See GFM syntax for referencing issues and commits.
  • Check the commits and commits messages and ensure they are free from typos.

Reporting Bugs and Creating Issues

For specifics on what to include in your report, please follow the guidelines in the issue and pull request templates when available.

Given that the image-registry-operator-api is currently the API surface to a larger project, please be aware that we must consider the wider impact of any API changes.

Ask for Help

The best way to reach us with a question when contributing is to ask on the original GitHub issue.