Skip to content

Latest commit

 

History

History
82 lines (73 loc) · 4.35 KB

MAINTAINERS.md

File metadata and controls

82 lines (73 loc) · 4.35 KB
Raw

Maintainers

This document aims to assist maintainers.

Envoy domain expertise

As a guideline, concepts in Nighthawk that are derived from Envoy require someone with Envoy domain expertise in review. Notable examples are the way Nighthawk internally computes cluster configuration, its connection pool derivations, the StreamDecoder class, as well as anything related to the Nighthawk test server.

See OWNERS.md to find maintainers with expertise of Envoy internals.

Pre-merge checklist

  • Does the PR have breaking changes? Then that should be explicitly mentioned in the version history.
  • New features should be added to the version history.
  • Breaking changes to the protobuf APIs are not allowed.
  • When merging, clean up the commit message so we get a nice history. By default, github will compile a message from all the commits that are squashed. The PR title and description should be a good starting point for the final commit message. (If it is not, it may be worth asking the PR author to update the description).
  • Make sure that the DCO signoff is included in the final commit message.
    • As a convention, it is appropriate to exclude content in the PR description that occurs after the signoff.

Updates to the Envoy dependency

We aim to synchronize our Envoy dependency with the latest revision weekly. Nighthawk reuses large parts of Envoy's build system and codebase, so keeping Nighthawk up to date with Envoy's changes is an important maintenance task. When performing the update, follow this procedure:

  1. Create a fork of Nighthawk, or fetch upstream and merge changes into your fork if you already have one.
  2. Create a new branch from main, e.g. envoy-update.
  3. Edit bazel/repositories.bzl
    1. Update ENVOY_COMMIT to the latest Envoy's commit from this page. (Clicking on the short commit id opens a page that contains the fully expanded commit id).
    2. Set ENVOY_SHA to an empty string initially, we will get the correct sha256 after the first bazel execution. Example content of bazel/repositories.bzl after the edits: 
      ENVOY_COMMIT = "9753819331d1547c4b8294546a6461a3777958f5"  # Jan 24th, 2021
ENVOY_SHA = ""
    3. Run ci/do_ci.sh build, notice the sha256 value at the top of the output, example: 
      INFO: SHA256 (https://github.com/envoyproxy/envoy/archive/9753819331d1547c4b8294546a6461a3777958f5.tar.gz) = f4d26c7e78c0a478d959ea8bc877f260d4658a8b44e294e3a400f20ad44d41a3
    4. Update ENVOY_SHA in bazel/repositories.bzl to this value.
  4. Sync (copy) .bazelrc from Envoy's version to update our build configurations. Be sure to retain our local modifications, all lines that are unique to Nighthawk are marked with comment # unique.
    1. If .bazelrc was modified, search for experimental_docker_image. Copy the SHA and update envoyproxy/envoy-build-ubuntu over at the top of .circleci/config.yml.
  5. Sync (copy) .bazelversion from Envoy's version to ensure we are using the same build system version.
  6. Sync (copy) ci/run_envoy_docker.sh from Envoy's version.
  7. Run ci/do_ci.sh test. Sometimes the dependency update comes with changes that break our build. Include any changes required to Nighthawk to fix that in the same PR.
  8. Create a PR with a title like Update Envoy to 9753819 (Jan 24th 2021), describe all performed changes in the PR's description.
  9. If the PR ends up modifying any c++ files, execute ci/do_ci.sh fix_format to reformat the files and avoid a CI failure.
  10. If the PR ends up modifying any CLI arguments, execute tools/update_cli_readme_documentation.sh --mode fix to regenerate the portion of our documentation that captures the CLI help output. This will prevent a CI failure.