Skip to content

Latest commit

 

History

History
80 lines (51 loc) · 3.59 KB

File metadata and controls

80 lines (51 loc) · 3.59 KB

How to Contribute to the OpenTelemetry Injector

We'd love your help!

This project is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, contact points and other resources to make it easier to get your contribution accepted.

We gratefully welcome improvements to documentation as well as to code.

Getting Started

Pre-requisites

  • Docker version 23.0.0 or greater.

Local development

The injector is written in Zig. To work on the injector source code it is recommended to install Zig on your machine. You can find the installation instructions here. Install the version referenced in zig-version. The Zig Version Manager is also a good alternative to installing one specific version of Zig.

See the page Zig Learn for more information about the language.

Makefile commands

  • make zig-build to build the injector binary locally on your machine
  • make watch-zig-build to continually rebuild the Zig sources on every change (requires fd and entr to be installed)
  • make zig-unit-tests to run the unit tests
  • watch-zig-unit-tests to continually run the Zig unit tests on every change (requires fd and entr to be installed)
  • make tests to run the unit tests and the injector integration tests
  • make rpm-package deb-package to build the RPM and Debian package
  • make packaging-integration-test-deb packaging-integration-test-rpm to rebuild the RPM and Debian packages and run integration tests against the newly built packages.

Github PR Workflow

It is recommended to follow the "GitHub Workflow". When using GitHub's CLI, here's how it typically looks like:

gh repo fork github.com/open-telemetry/opentelemetry-injector
git checkout -b your-feature-branch
# do your changes
git commit -sam "Add feature X"
gh pr create

Contributing

Your contribution is welcome! For it to be accepted, we have a few standards that must be followed.

New features

Before starting the development of a new feature, please create an issue and discuss it with the project maintainers. Features should come with documentation and enough tests (unit and/or end-to-end).

Bug fixes

Every bug fix should be accompanied by a unit test, so that we can prevent regressions.

Documentation, typos, ...

They are mostly welcome!

Adding a Changelog Entry

The CHANGELOG.md file in this repo is autogenerated from .yaml files in the ./.chloggen directory.

Your pull-request should add a new .yaml file to this directory. The name of your file must be unique since the last release.

During the collector release process, all ./.chloggen/*.yaml files are transcribed into CHANGELOG.md and then deleted.

If a changelog entry is not required, add either chore to the title of the pull request or add the "Skip Changelog" label to disable this action.

Recommended Steps

  1. Create an entry file using make chlog-new. This generates a file based on your current branch (e.g. ./.chloggen/my-branch.yaml)
  2. Fill in all fields in the new file
  3. Run make chlog-validate to ensure the new file is valid
  4. Commit and push the file

Alternately, copy ./.chloggen/TEMPLATE.yaml, or just create your file from scratch.