Contributing guidelines

View as Markdown

This file is intended to provide some guidelines regarding the code, the repository, and the practices to follow when contributing to the development of Krenalis.

Before opening a pull request

Check the licenses

Area License
Core, Admin console Elastic License 2.0
Connectors, Warehouses, SDKs MIT (Open Source)

Guidelines

  • Code that introduces a connector or warehouse platform for a data warehouse must be released under the MIT License.

  • Code that contributes to the Core or any other area covered by the Elastic License v2 must comply with that license and include acceptance of the Contributor License Agreement (CLA).

  • Dependencies
    In general, pull requests should not add new external dependencies. Exceptions apply to new connectors for databases, files, or file storages, which may require dependencies to connect, read, or write specific formats. Dependencies must use MIT, BSD, or Apache 2.0 licenses. Any other license requires prior approval.

  • Third-party code
    If you need to include third-party code, it must have been distributed by its author under an MIT, BSD, or Apache 2.0 license.

    • For a few lines of code, you may include them inline, but clearly mark them and cite the original author and license.
    • For larger portions, place the code in a separate file with the author and license explicitly stated in the file header.

Run automated checks locally

Before proceeding, make sure you have all the necessary dependencies installed locally. For the complete list of them, please refer to: https://github.com/krenalis/krenalis/blob/main/.github/workflows/go-run-test-commit.yml.

Run go run ./test/commit -no-connector-tests before opening the pull request.

Altering the tests configuration

The tests inside /test/ are already configured by default when the repository is clean, and they can be run as they are; however, in certain circumstances, it may become necessary to modify the test configuration, perhaps to meet a specific configuration of the system that runs them. Below are the documented environment variables that affect the tests:

Variable Description Default
KRENALIS_TESTS_ADDR The host and port on which Krenalis is started 127.0.0.1:2023
KRENALIS_TESTS_PYTHON_PATH The path to the Python executable for running the transformation functions It depends on the system

Good commit messages

The following is an example of a good commit message:

core/http: normalize `Accept-Language` header

Align the header parser with RFC 9110, removing superfluous spaces and
sorting locales by quality. This prevents cache misses when the browser
sends duplicate values.

Fixes #2031

  • First line. Write a concise, one-line summary of the change, starting with the relevant package path as a prefix. If multiple packages are affected, separate them with commas or use a common ancestor. After the prefix, use the present tense imperative form (e.g., "fix ...", not "fixed ...").

  • Main content. Explain what the change does and why it was made. Use clear, complete sentences. Avoid HTML and complex Markdown. Basic Markdown (lists, code, quotes) is fine.

  • Line length. Each line should be no longer than 72 characters.

  • Names. When referring to identifiers or code elements, enclose them in backticks (like this `) in the commit title, and in single quotes (like this ') in the remaining lines.