Pull request review guidelines
The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is generally available and ready for production usage. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Stack
Generally available
Every change made to Beats must be held to a high standard, and while the responsibility for quality in a pull request ultimately lies with the author, Beats team members have the responsibility as reviewers to verify during their review process. Where this document is unclear or inappropriate let common sense and consensus override it.
Everyone’s got an opinion on style. To avoid spending time on this issue we rely almost exclusively on go fmt and hound to police style. If neither of these tools complain the code is almost certainly fine. There may be exceptions to this, but they should be extremely rare. Only override the judgement of these tools in the most unusual of situations.
As software projects grow so does the complexity of their test cases and with that the probability of some tests becoming flaky. It is everyone’s responsibility to handle flaky tests. If you notice a pull request build failing for a reason that is unrelated to the pushed code follow the procedure below:
- Create an issue using the "Flaky Test" github issue template with the "Flaky Test" label attached.
- Create a PR to mute or fix the flaky test.
- Merge that PR and rebase off of it before continuing with the normal PR process for your original PR.