Thank you for your interest in contributing to the Devfile Registry! We welcome your additions to this project.
Before contributing to this repository for the first time, please review our project's Code of Conduct.
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.
If you spot a problem with the devfile registry, 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 related issues with the /area registry text in your issue.
The registry-support repository for the devfile registry is a mono-repo of sorts and there are a number of individual components contained within.
- Devfile Registry Build Tools - Tools for building devfile registries into container images.
- Devfile Registry Helm Chart - Helm chart for deploying the devfile registry on to Kubernetes.
- Index Generator - The index generator tool for generation index.json files from registry data
- Index Server - The index server, one of two servers that the devfile registry runs
- OCI Registry Server - The OCI registry server, the second of two servers that the devfile registry runs.
Each of these individual components will have their own readme with instructions for consuming or developing the component, and it's recommended to consult them before development.
This repository contains a handy script that will build all of the individual components of the devfile registry (build-tools, index generator, index server, registry viewer, etc) and produce a deployable container image containing test devfile data.
All changes delivered for the Devfile Registry are expected to be sufficiently tested. This may include validating that existing tests pass, updating tests, or adding new tests. Some of the components in this repository may have their own tests, others may just be covered by the repository's integration tests.
Unit tests for each component are denoted by files with the _test.go suffix.
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.
To run these tests, consult the integration test's readme.
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 run by default 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.
If you have any questions, please visit us the #devfile channel under the Kubernetes Slack workspace.