First, thank you for contributing to Vector! The goal of this document is to clearly provide everything you need to start contributing to Vector. The following TOC is sorted in a progressive fashion, starting with the basics and expanding into more specifics.
- What is conventional commits?
- Do I need to update the changelog?
- What is a DCO?
- Why does Vector adopt the DCO?
- Why a DCO instead of a CLA?
- What about trivial changes?
- Granted rights and copyright assignment
- If I’m contributing while an employee, do I still need my employer to sign something?
- What if I forgot to sign my commits?
All changes must be made in a branch and submitted as pull requests. Vector does not adopt any type of branch naming style, but please use something descriptive of your changes.
Please ensure your commits are small and focused; they should tell a story of your change. This helps reviewers to follow your changes, especially for more complex changes.
Your commits must include a DCO signature. This is simpler than it sounds; it just means that all of your commits must contain:
Signed-off-by: Joe Smith <firstname.lastname@example.org>
Git makes this easy by adding the
--signoff flags when you commit:
git commit -sm 'My commit message'
We also included a
make signoff target that handles this for you if
Github Pull Requests
Once your changes are ready you must submit your branch as a pull
The follow are all good examples of pull request titles:
feat(new sink): new `xyz` sink feat(tcp source): add foo bar baz feature fix(tcp source): fix foo bar baz bug chore: improve build process docs: fix typos
At least one Vector team member must approve your work before merging. All pull requests are squashed and merged. We generally discourage large pull requests that are over 300-500 lines of diff. If you would like to propose a change that is larger we suggest coming onto our gitter channel and discuss it with one of our engineers. This way we can talk through the solution and discuss if a change that large is even needed! This overall will produce a quicker response to the change and likely produce code that aligns better with our process.
Currently Vector uses CircleCI. The build process
is defined in
/.circleci/config.yml. This delegates heavily to the
distribution/docker folder where Docker images are
defined for all of our testing, building, verifying, and releasing.
Tests are run for all changes, and Circleci is reponsible for releasing updated versions of Vector through various channels.
Install Rust via
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Install Docker. Docker containers are used for mocking Vector's integrations.
/benches- Internal benchmarks.
/config- Public facing Vector config, included in releases.
/distribution- Distribution artifacts for various targets.
/docs- https://vector.dev/docs/ source.
/lib- External libraries that do not depend on
vectorbut are used within the project.
/proto- Protobuf definitions.
/scripts- Scripts used to generate docs and maintain the repo.
/tests- Various high-level test cases.
Vector includes a
Makefile in the root of the repo. This serves
as a high-level interface for common commands. Running
make will produce
a list of make targets with descriptions. These targets will be referenced
throughout this document.
stable to format our code and CI will verify that your
this format style. To run the following command make sure
rustfmt has been
installed on the stable toolchain locally.
# To install rustfmt rustup component add rustfmt # To format the code make fmt
Documentation is extremely important to the Vector project. Ideally, all contributions that will change or add behavior to Vector should include the relevant updates to the documentation website.
The project attempts to make documentation updates as easy as possible, reducing most of it down to a few small changes which are outlined in DOCUMENTING.md.
Regardless of whether your changes require documentation updates you should
make generate before attempting to merge your commits.
Building a sink
Sinks may implement a healthcheck as a means for validating their configuration against the envionment and external systems. Ideally, this allows the system to inform users of problems such as insufficient credentials, unreachable endpoints, non-existant tables, etc. They're not perfect, however, since it's impossible to exhaustively check for issues that may happen at runtime.
Guidelines for writing healthchecks
When implementing healthchecks, we prefer false positives to false negatives. This means we would prefer that a healthcheck pass and the sink then fail than to have the healthcheck fail when the sink would have been able to run successfully.
A common cause of false negatives in healthchecks is performing an operation that the sink itself does not need. For example, listing all of the available S3 buckets and checking that the configured bucket is in that list. The S3 sink doesn't need the ability to list all buckets, and a user that knows that may not have given it permission to do so. In that case, the healthcheck will fail due to bad credentials even through its credentials are sufficient for normal operation.
This leads to a general strategy of mimicking what the sink itself does. Unfortunately, the fact that healthchecks don't have real events available to them leads to some limitations here. The most obvious example of this is with sinks where the exact target of a write depends on the value of some field in the event (e.g. an interpolated Kinesis stream name). It also pops up for sinks where incoming events are expected to conform to a specific schema. In both cases, random test data is reasonably likely to trigger a potentially false negative result. Even in simpler cases, we need to think about the effects of writing test data and whether the user would find that surprising or invasive. The answer usually depends on the system we're interfacing with.
In some cases, like the Kinesis example above, the right thing to do might be nothing at all. If we require dynamic information to figure out what entity (i.e. Kinesis stream in this case) that we're even dealing with, odds are very low that we'll be able to come up with a way to meaningfully validate that it's in working order. It's perfectly valid to have a healthcheck that falls back to doing nothing when there is a data dependency like this.
With all that in mind, here is a simple checklist to go over when writing a new healthcheck:
- Does this check perform different fallible operations from the sink itself?
- Does this check have side effects the user would consider undesirable (e.g. data pollution)?
- Are there situations where this check would fail but the sink would operate normally?
Not all of the answers need to be a hard "no", but we should think about the likelihood that any "yes" would lead to false negatives and balance that against the usefulness of the check as a whole for finding problems. Because we have the option to disable individual healthchecks, there's an escape hatch for users that fall into a false negative circumstance. Our goal should be to minimize the likelihood of users needing to pull that lever while still making a good effort to detect common problems.
You can run Vector's tests via the
make test command. Our tests use Docker
compose to spin up mock services for testing, such as
flog to build a sample set of log files to test sending logs from a
file. This can be done with the following commands on mac with homebrew.
Installation instruction for flog can be found
flog --bytes $((100 * 1024 * 1024)) > sample.log
This will create a
100MiB sample log file in the
All benchmarks are placed in the
/benches folder. You can
run benchmarks via the
make benchmarks command.
What is conventional commits?
Conventional commits is a standardized
format for commit messages. Vector only requires this format for commits on
master branch. And because Vector squashes commits before merging
branches, this means that only the pull request title must conform to this
format. Vector performs a pull request check to verify the pull request title
in case you forget.
Do I need to update the changelog?
Nope! This is one of the primary reasons we use the conventional commits style. Before releasing Vector we'll automatically generate a changelog for the release.
What is a DCO?
DCO stands for Developer Certificate of Origin and is maintained by the Linux Foundation. It is an attestation attached to every commit made by every developer. It ensures that all committed code adheres to the Vector license (Apache 2.0).
Why does Vector adopt the DCO?
To protect the users of Vector. It ensures that all Vector contributors, and committed code, agree to the Vector license.
Why a DCO instead of a CLA?
It's simpler, clearer, and still protects users of Vector. We believe the DCO more accurately embodies the principles of open-source. More info can be found here:
What about trivial changes?
Trivial changes, such as spelling fixes, do not need to be signed.
Granted rights and copyright assignment
It is important to note that the DCO is not a license. The license of the project – in our case the Apache License – is the license under which the contribution is made. However, the DCO in conjunction with the Apache License may be considered an alternate CLA.
The existence of section 5 of the Apache License is proof that the Apache License is intended to be usable without CLAs. Users need for the code to be open source, with all the legal rights that implies, but it is the open source license that provides this. The Apache License provides very generous copyright permissions from contributors, and contributors explicitly grant patent licenses as well. These rights are granted to everyone.
If I’m contributing while an employee, do I still need my employer to sign something?
Nope! The DCO confirms that you are entitled to submit the code, which assumes that you are authorized to do so. It treats you like an adult and relies on your accurate statement about your rights to submit a contribution.
What if I forgot to sign my commits?
No probs! We made this simple with the
signoff Makefile target:
If you prefer to do this manually: