First of all, thanks for contributing!
This document aims to provide some basic guidelines to contribute to this repository, but keep in mind that these are just guidelines, not rules; use your best judgment and feel free to propose changes to this document in a pull request.
- You can first take a look at the Troubleshooting section of our Knowledge base.
- If you can't find anything useful, please contact our support and send them your logs.
- Finally, you can open a Github issue respecting this convention (it helps us triage).
You wrote some code/added a new check and want to share it? Thanks a lot for your interest!
In order to ease/speed up our review, here are some items you can check/improve when submitting your PR:
- have a proper commit history (we advise you to rebase if needed).
- write tests for the code you wrote.
- preferably make sure that all tests pass locally.
- summarize your PR with a good title and a message describing your changes, cross-referencing any related bugs/PRs.
Your Pull Request must always pass all the CI tests before being merged, if you think the error is not due to your changes, you can have a talk with us on Slack (datadoghq.slack.com) or send us an email to support at datadoghq dot com)
If you are adding a dependency (python module, library, ...), please check the corresponding section.
Most of the checks live in the Integration SDK. Please look there to submit related issues, PRs, or review the latest changes.
For new integrations, please open a pull request in the integrations extras repo
Avoid changing too many things at once, for instance if you're fixing the redis integration and at the same time shipping a dogstatsd improvement, it makes reviewing harder (devs specialize in different parts of the code) and the change time-to-release longer.
Every commit should lead to a valid code, at least a code in a better state than before. That means that every revision should be able to pass unit and integration tests (more about testing)
An example of something which breaks bisectability:
- commit 1: Added check X
- commit 2: forgot column
- commit 3: fix typo
To avoid that, please rebase your changes and create valid commits. It keeps history cleaner, it's easier to revert things, and it makes developers happier too.
Please don't use git commit -m "Fixed stuff", it usually means that you just wrote the very first thing that came to your mind without much thought. Also it makes navigating through the code history harder.
Instead, the commit shortlog should focus on describing the change in a sane way (see commits titles) and be short (72 columns is best).
The commit message should describe the reason for the change and give extra details that will allow someone later on to understand in 5 seconds the thing you've been working on for a day.
If your commit is only shipping documentation changes or example files, and is a complete no-op for the test suite, please add [skip ci] in the commit message body to skip the build and let you build slot to someone else in need 😉
Examples, see:
- https://github.com/DataDog/dd-agent/commit/44bc927aaaf2925ef081768b5888bbb20a5bb3bd
- https://github.com/DataDog/dd-agent/commit/677417fe12b1914e4322ac2c1fd1645cb0f1de31
- and for more general guidance, this should help
Every commit title, PR or issue should be named like the following example:
[category] short description of the matter
category can be:
- core: for the agent internals, or the common interfaces
- dogstatsd: for the embedded dogstatsd server
- tests: related to CI, integration & unit testing
- dev: related to development or tooling
- check_name: specific to one check
For descriptions, keep it short keep it meaningful. Here are a few examples to illustrate.
- [mysql] mysql check does not work
- [snmp] improved snmp
- [core] refactored stuff
- [mysql] exception ValueError on mysql 5.4
- [snmp] added timeouts to snmpGet calls
- [core] add config option to common metric interface
You wrote a new agent check which uses a dependency not embedded in the agent yet? You're at the right place to correct this!
We use Omnibus to build our agent and bundle all dependencies and we define what are the agent
dependencies in the omnibus folder.