Skip to content

Latest commit

 

History

History
152 lines (94 loc) · 6.7 KB

CONTRIBUTING.md

File metadata and controls

152 lines (94 loc) · 6.7 KB
Raw

Contributing

Thank you for your interest in contributing to the Devfile Registry Operator! We welcome your additions to this project.

Code of Conduct

Before contributing to this repository for the first time, please review our project's Code of Conduct

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.

In order to show your agreement with the DCO you should include at the end of the commit message, the following line:

Signed-off-by: Firstname Lastname <email@email.com>

Once you set your user.name and user.email in your git config, you can sign your commit automatically with git commit -s.

How to Contribute

Issues

If you spot a problem with the devfile registry operator, search if an issue already exists.

If a related issue doesn't exist, you can open a new issue using a relevant issue form. You can tag Devfile Registry Operator related issues with the /area registry text in your issue.

Development

First Time Setup

  1. Install prerequisites: see Requirements section in README.

  2. Fork and clone this repository.

  3. Open the folder in the IDE of your choice (VS Code with Go extension, or GoLand is recommended)

Build and Run the Operator

The Makefile currently supports both Docker and Podman. To run the proper command replace <engine> with either podman or docker depending on your container engine.

  1. Log in to an OpenShift or Kubernetes cluster

  2. Run export IMG=<operator-image> where <operator-image> is the image repository to where you would like to push the image (e.g. quay.io/user/registry-operator:latest).

  3. Run make <engine>-build to build the devfile registry operator.

  4. Run make <engine>-push to push the devfile registry operator image.

  5. (Optional, docker only) Run make docker-buildx to build and push the devfile registry operator multi-architecture image.

  6. Run make install-cert to install the cert-manager. (Allow time for these services to spin up before moving on to step 7 & 8).

  7. Run make install to install the CRDs.

  8. Run make deploy to deploy the operator.

Enabling HTTP/2 on the Webhook Server

By default, http/2 on the webhook server is disabled due to CVE-2023-44487.

If you want to enable http/2 for the webhook server, build with ENABLE_WEBHOOK_HTTP2=true make <engine>-build or with ENABLE_WEBHOOK_HTTP2=true make run if running locally.

Using other platforms

If you need to target another platform for container builds, such as Apple silicon, you can use TARGET_ARCH=<architecture> make <engine>-build.

For example, to target container build to arm64 run the following:

TARGET_ARCH=arm64 make <engine>-build

Note: Container builds only use linux as the operating system as local cluster runtime environments, such as minikube environments, run under Linux virtual machines for other operating systems. For example, Apple silicon would just use the arm64 container build.

For local builds, you can also set the target operating system:

Apple silicon

export TARGET_OS=darwin
export TARGET_ARCH=arm64
make manager

Linux ARM

export TARGET_ARCH=arm64
make manager

Windows

export TARGET_OS=windows
export TARGET_ARCH=amd64
make manager

By default, amd64 is used for the target architecture and linux is used for the target operating system.

Testing your Changes

All changes delivered to the Devfile Registry Operator are expected to be sufficiently tested. This may include validating that existing tests pass, updating tests, or adding new tests.

Unit Tests

The unit tests for this repository are located under the pkg/ folder and are denoted with the _test.go suffix. The tests can be run by running make test.

Integration Tests

The integration tests for this repository are located under the tests/integration folder and contain tests that validate the Operator's functionality when running on an OpenShift cluster.

One of the oc or kubectl executables must be accessible. If both are present in your path, oc will be used, except if you define the environment variable K8S_CLI with the command you prefer to use.

By default, the tests will use the default image for the operator, quay.io/devfile/registry-operator:next.

You can use make <engine>-build to build your own image, make <engine>-push to publish it - Replace <engine> with podman or docker. You will need to have a reference to your newly built image available via the IMG environment variable.

In order for make test-integration to properly run you must first ensure your environment is prepared for the operator. The following steps should be done before running make test-integration and these commands should be run from the root of the repository where the Makefile is located.

  1. Run make install-cert and wait for pods in the cert-manager namespace to be running before moving to step 2.
  2. Run make install && make deploy and wait until pods in the registry-operator-system namespace are running before proceeding to step 3.
  3. Run make test-integration or IMG=<your-operator-image> make test-integration to run the integration tests.

Submitting Pull Request

Note: All commits must be signed off with the footer:

Signed-off-by: First Lastname <email@email.com>

You can easily add this footer to your commits by adding -s when running git commit. When you think the code is ready for review, create a pull request and link the issue associated with it.

Owners of the repository will watch out for new PRs and provide reviews to them.

For each change in the PR, GitHub Actions and OpenShift CI will by default run checks against your changes (linting, unit testing, and integration tests).

If comments have been given in a review, they have to be addressed before merging.

After addressing review comments, don't forget to add a comment in the PR with the reviewer mentioned afterward, so they get notified by Github to provide a re-review.

Contact us

If you have any questions, please visit the #devfile channel under the Kubernetes Slack workspace.