Skip to content

Latest commit

 

History

History
44 lines (32 loc) · 2.71 KB

CONTRIBUTING.md

File metadata and controls

44 lines (32 loc) · 2.71 KB

Contributing to DNS Operator

Thank you for your interest in contributing to DNS Operator! We welcome contributions from the community to help improve and grow this project. Before contributing, please take a moment to review the following guidelines.

Local setup

To set up DNS Operator locally, follow the Getting Started steps in the readme

Code Layout Overview

DNS Operator follows a specific code layout to maintain consistency and readability. Here's an overview of the key directories:

  • cmd/: This is the main entry point of the application.
  • internal/: Houses the core functionality of DNS Operator, organized into subpackages. also contains all the unit tests and integration tests for each subpackage in the *_test.go files.
    • common/: A few functions generally useful in the rest of the codebase.
    • controller/: The controllers for the DNS Record CR and the Managed Zone CR.
    • external-dns/: copied and changed slightly from external-dns, ultimately expected to send these changes back to external-dns and delete this directory, more info in the pull request.
    • provider/: Interface to various DNS Providers (e.g. AWS Route53).
  • test/: Includes test files for e2e testing.
  • docs/: The documentation for the DNS Operator.

Other directories (less frequently interacted with manually):

  • api/: This contains the various CRDs this operator owns, defined in go code.
  • bin/: Used to store binaries required by various Makefile commands.
  • bundle/: Generated by Makefile commands.
  • config/: The files used by kustomize for this operator.
  • hack/: A few useful files, that are useful for local development.
  • make/: Various additional Makefile commands.

Coding Standards

When contributing code to DNS Operator, please adhere to the following coding standards:

  • Follow the Golang coding style guide.
  • Write clear and concise code with meaningful variable and function names.
  • Include comments to explain non-obvious code sections.
  • Ensure new (or altered) code is covered by unit tests, integration tests and e2e tests as much as is possible and useful.
  • Ensure your code passes all tests and linters.
    • This can be ensured locally using make verify-all

Test Overview

DNS Operator relies on comprehensive testing to maintain stability and reliability. We utilize both unit tests and integration tests to verify functionality. When new changes or features are added it is expected that existing tests will be modified to both continue passing and also adequately test the new changes.

For more information on how to run the tests locally, see the Testing section of the readme.