Project: Vector (Observability and Analysis / Observability)
File: CONTRIBUTING.md

First, thank you for contributing to Vector! The goal of this document is to provide everything you need to start contributing to Vector. The following TOC is sorted progressively, starting with the basics and expanding into more specifics. Everyone from a first time contributor to a Vector team member will find this document useful. - - - - - - - - - - - You're familiar with and the pull request workflow. You've read Vector's . You know about the . Please use this for help. Ensure your change has an issue! Find an or . This is where you can get a feel if the change will be accepted or not. Changes that are questionable will have a `needs: approval` label. Once approved, in your own GitHub account (only applicable to outside contributors). . Make your changes. to the main Vector repo. A Vector team member should comment and/or review your pull request within a few days. Although, depending on the circumstances, it may take longer. If you're thinking of contributing a new source, sink, or transform to Vector, thank you that's way cool! The answers to the below questions are required for each newly proposed component and depending on the answers, we may elect to not include the proposed component. If you're having trouble with any of the questions, we're available to help you. Prior to beginning work on a new source or sink if a GitHub Issue does not already exist, please open one to discuss the introduction of the new integration. Maintainers will review the proposal with the following checklist in mind, try and consider them when sharing your proposal to reduce the amount of time it takes to review your proposal. This list is not exhaustive, and may be updated over time. [ ] Can the proposed components functionality be replicated by an existing component, with a specific configuration? (ex: Azure Event Hub as a `kafka` sink configuration) [ ] Alternatively implemented as a wrapper around an existing component.

`axiom` wrapping `elasticsearch`) [ ] Can an existing component replicate the proposed components functionality, with non-breaking changes? [ ] Can an existing component be rewritten in a more generic fashion to cover both the existing and proposed functions? [ ] Is the proposed component generically usable or is it specific to a particular service? [ ] How established is the target of the integration, what is the relative market share of the integrated service? [ ] Is there sufficient demand for the component? [ ] If the integration can be served with a workaround or more generic component, how painful is this for users? [ ] Is the contribution from an individual or the organization owning the integrated service? (examples of organization backed integrations: `databend` sink, `axiom` sink) [ ] Is the contributor committed to maintaining the integration if it is accepted? [ ] What is the overall complexity of the proposed design of this integration from a technical and functional standpoint, and what is the expected ongoing maintenance burden? [ ] How will this integration be tested and QAd for any changes and fixes? [ ] Will we have access to an account with the service if the integration is not open source? To merge a new source, sink, or transform, the pull request is required to: [ ] Add tests, especially integration tests if your contribution connects to an external service. [ ] Add instrumentation so folks using your integration can get insight into how it's working and performing. You can see some . . When adding new integration tests, the following changes are needed in the GitHub Workflows: in `.github/workflows/integration.yml`, add another entry in the matrix definition for the new integration. in `.github/workflows/integration-comment.yml`, add another entry in the matrix definition for the new integration. in `.github/workflows/changes.yml`, add a new filter definition for files changed, and update the `changes` job outputs to reference the filter, and finally update the outputs of `workflow_call` to include the new filter. All changes must be made in a branch and submitted as . If you want your branch to have a website preview build created, include the word `website` in the branch. Otherwise, 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. Once your changes are ready you must submit your branch as a . The pull request title must follow the format outlined in the . is a standardized format for commit messages. Vector only requires this format for commits on the `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. A list of allowed sub-categories is defined . The following are all good examples of pull request titles: ```text 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 ``` All pull requests should be reviewed by: No review required for cosmetic changes like whitespace, typos, and spelling by a maintainer One Vector team member for minor changes or trivial changes from contributors Two Vector team members for major changes Three Vector team members for RFCs If CODEOWNERS are assigned, a review from an individual from each of the sets of owners is required. 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 and discuss it with one of our

This way we can talk through the solution and discuss if a change that large is even needed! This will produce a quicker response to the change and likely produce code that aligns better with our process. By default, all pull requests are assumed to include user-facing changes that need to be communicated in the project's changelog. If your pull request does not contain user-facing changes that warrant describing in the changelog, add the label 'no-changelog' to your PR. When in doubt, consult the vector team for guidance. The details on how to add a changelog entry for your PR are outlined in detail in . Currently, Vector uses GitHub Actions to run tests. The workflows are defined in `.github/workflows`. GitHub Actions is responsible for releasing updated versions of Vector through various channels. Tests are run for all changes except those that have the label: ```text ci-condition: skip ``` Some long-running tests are only run daily, rather than on every pull request. If needed, an administrator can kick off these tests manually via the button on the [nightly build action page](https://github.com/vectordotdev/vector/actions?query=workflow%3Anightly) Historically, we've had some trouble with tests being flakey. If your PR does not have passing tests: Ensure that the test failures are unrelated to your change Is it failing on master? Does it fail if you rerun CI? Can you reproduce locally? Find or open an issue for the test failure () Link the PR in the issue for the failing test so that there are more examples You can invoke the by commenting on any pull request with: ```bash /test -t <name> ``` To run tests locally, use . Unit tests can be run by calling `cargo vdev test`. Integration tests are not run by default when running `cargo vdev test`. Instead, they are accessible via the integration subcommand (example: `cargo vdev int test aws` runs aws-related integration tests). You can find the list of available integration tests using `cargo vdev int show`. Integration tests require docker or podman to run. There are other checks that are run by CI before the PR can be merged. These should be run locally first to ensure they pass. ```sh cargo vdev check rust cargo vdev check fmt cargo vdev check events cargo vdev check licenses make check-component-docs cd rust-doc && make docs ``` When deprecating functionality in Vector, see . When adding, modifying, or removing a dependency in Vector you may find that you need to update the inventory of third-party licenses maintained in `LICENSE-3rdparty.csv`. This file is generated using and can be updated using `cargo vdev build licenses`. As discussed in the , you should continue to the following documents: - Everything necessary to develop - Preparing your change for Vector users - Deprecating functionality in Vector To protect all users of Vector, the following legal requirements are made. If you have additional questions, please [contact us]. Vector requires all contributors to sign the Contributor License Agreement (CLA). This gives Vector the right to use your contribution as well as ensuring that you own your contributions and can use them for other purposes. The full text of the CLA can be found at . This is covered by the CLA.