Contributions of all kinds are welcome. In particular pull requests are appreciated. The authors and maintainers will endeavor to help walk you through any issues in the pull request discussion, so please feel free to open a pull request even if you are new to such things.
Note
This repository is used in Konflux. Therefore, everybody should follow its Code of Conduct.
- We encourage early communication for all types of contributions.
- Before filing an issue, make sure to check if it is not reported already.
- If the contribution is non-trivial (straightforward bugfixes, typos, etc.), please open an issue to discuss your plans and get guidance from maintainers.
- Fork and Clone: Fork this repository and clone your fork
- Create Feature Branch: Create a new topic branch based on
main - Make Changes: Implement your changes. Consult README.md for the structure and development details.
- Commit Changes: See commit guidelines
Commit Requirements:
- Write clear, descriptive commit titles. Should fit under 50 characters
- Write meaningful commit descriptions with each line having less than 72 characters
- Split your contribution into several commits if applicable, each should represent a logical chunk
- Add line
Assisted-by: <name-of-ai-tool>if you used an AI tool for your contribution - Sign-off your commits in order to certify that you adhere to Developer Certificate of Origin
Pull Request Content:
- Title: Clear, descriptive title. Should fit under 72 characters.
- Description: Explain the overall changes and their purpose, this should be a cover letter for your commits.
- Testing: Describe how the changes were tested
- Links: Reference related issues or upstream stories.
Remember:
- Konflux is a community project and proper descriptions cannot be replaced by referencing a publicly inaccessible link to Jira or any other private resource.
- Reviewers, other contributors and future generations might not have the same context as you have at the moment of PR submission.
- Never commit secrets or keys to the repository
- Never expose or log sensitive information
Requirements for Approval:
- All CI checks pass
- Code review approval from maintainers
Review Criteria:
- The contribution follows established patterns and conventions
- Changes are tested and documented
- Security best practices are followed
For any questions or help with contributing, please open an issue or reach out to the maintainers.
Tests are written using the Ginkgo framework. Here is some general advice when writing tests:
- When the global
Describedoesn't add enough context to the tests, use a nestedDescribeor aContextto specify what this test alludes to. Contexts should always start with When (i.e. "When calling the function Foo") - Start the descriptions of
Itblocks in lowercase and try to be as descriptive as possible - Avoid ignoring errors. In other words, make sure all of them are caught and tested
- Files ending with
_suite_test.goare meant to store the code that is common for tests in the same directory and that will be executed before them. Use these files only if your test setup is big enough to justify it (ie. the suite file has more than the test suite name and the teardown) - When required, remember to add the required CRDs during the
envtestsetup. See the example snapshot_suite_test.go file for an example of how to configureCRDDirectoryPathsin the test environment. This setup is essential for tests to run properly and can save significant debugging time - After
Create()orUpdate()objects, useGet()before making assurances as the object might be outdated. It is useful afterDelete()to check if the client returnserrors.IsNotFound - Some assurances are likely to require usage of
Eventuallyblocks instead of or in addition toExpectblocks
Links that may be used as a starting point:
- Getting started with Ginkgo
- Gomega reference doc
- Writing controller tests
- Testing your Operator project
Unofficial (but useful) links: