CONTRIBUTING.md

[comment]: # ( Copyright Contributors to the Open Cluster Management project )Table of Contents

• Contributing guidelines
  • Terms
  • Certificate of Origin
  • Contributing a patch
  • Issue and pull request management
• Requirements
• Develop new commands
  • Resources
  • Prepare development environment
  • build
  • API
  • Unit tests
  • Functional tests
  • Make a release (Owners only)

Contributing guidelines

Terms

All contributions to the repository must be submitted under the terms of the Apache Public License 2.0.

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.

Contributing a patch

1. Submit an issue describing your proposed change to the repository in question. The repository owners will respond to your issue promptly.
2. Fork the desired repository, then develop and test your code changes.
3. Submit a pull request.

Issue and pull request management

Anyone can comment on issues and submit reviews for pull requests. In order to be assigned an issue or pull request, you can leave a /assign <your Github ID> comment on the issue or pull request.

Requirements

• Go 1.16

Develop new commands

• The project tries to follow the following grammar for the commands:

cm <verb> [subcmd...] [flags]

• cmd/subcmd has its own package. For example delete/cluster package contains the code to create a cluster.

• Inside the package, the code is split in 3 files: The cmd.go which creates the cobra command, the options.go which defines the different option parameters for the command and the the exec.go which contains the code to execute the command.

Resources

• Some commands needs resources files, in the project uses the Go 1.16 go:embed functionality to store the resources files.
• Each command package contains its own resources in the scenario package. The scenario package contains one go file which provides the go:embed embed.FS files. For example resources.go.
• All resources must be accessed using unstrusctured, the project must not have api dependencies.

Prepare development environment

1. kubebuilder must be installed, if not run make kubebuilder-tools.
2. etcd must be instaled, if not run make envtest-tools.
3. The environment variable KUBEBUILDER_ASSETS must be set to your kubebuilder binary (ie: export KUBEBUILDER_ASSETS=$HOME/kubebuilder/bin or sudo mv $HOME/kubebuilder /usr/local)

build

make build doc-help

API

This project contains some API and these are used in order to leverage the "github.com/kubernetes/cli-runtime/blob/master/pkg/printers/interface.go. To generate the zz_files for it run make generate

Unit tests

• If the unit test needs files to be executed, these files are stored under the pair <verb>/<noun>/test/unit like values-fake/yaml. A total coverage is shown when running make test. For the time being, the cmd.go and client.go are excluded from the total coverage.
• The make test is part of the PR acceptance and it is launched by PROW.

Functional tests

• The project runs functional-tests make functional-test-full, this test deploys a KiND cluster, install some resource using the applier and then runs a set of tests against that cluster run-functional-tests.sh. A prerequisite is that Docker is already running. If it fails then clean with make clean.
• The make functional-tests-full is part of the PR acceptance and it is launched using git-actions.

Make a release (Owners only)

1. Create a branch
2. run make doc-help
3. Update the VERSION.txt with the semver of the new release (if not yet done)
4. Create a PR and merge it
5. Run make release on the main branch
6. Monitor the github action.
7. Go to releases on github
8. Review the summary.
9. Publish