Updating references to branch name master->main.

CONTRIBUTING.md

@@ -8,30 +8,30 @@ maximize the chances of your PR being merged.
 
 # Coding style
 
-* Coding style mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/STYLE.md)
+* Coding style mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/main/STYLE.md)
 
 # Breaking change policy
 
 Both API and implementation stability are important to Nighthawk. Since the API is consumed by clients beyond Nighthawk, breaking changes to that are prohibited.
 
 # Submitting a PR
 
-* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#submitting-a-pr) with respect to PR submission policy.
+* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#submitting-a-pr) with respect to PR submission policy.
 * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as
   well as [release notes](docs/root/version_history.md).
 
 # PR review policy for maintainers
 
-* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to maintainer review policy.
+* Generally Nighthawk mirrors [Envoy's policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#pr-review-policy-for-maintainers) with respect to maintainer review policy.
 * See [OWNERS.md](OWNERS.md) for the current list of maintainers.
 * It is helpful if you apply the label `waiting-for-review` to any PRs that are ready to be reviewed by a maintainer.
   * Reviewers will change the label to `waiting-for-changes` when responding.
 
 # DCO: Sign your work
 
-Commits need to be signed off. See [here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#dco-sign-your-work).
+Commits need to be signed off. See [here](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#dco-sign-your-work).
 
 
 ## Triggering CI re-run without making changes
 
-See [here](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md#triggering-ci-re-run-without-making-changes).
+See [here](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#triggering-ci-re-run-without-making-changes).

MAINTAINERS.md

@@ -29,6 +29,6 @@ Envoy internals.
 We try to [regularly synchronize our Envoy dependency](https://github.com/envoyproxy/nighthawk/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+%22update+envoy%22+) with the latest revision. Nighthawk reuses large parts of Envoy's build system and CI infrastructure. When we update, that looks like:
 
 - A change to [repositories.bzl](bazel/repositories.bzl) to update the commit and SHA.
-- A sync of [.bazelrc](.bazelrc) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/master/.bazelrc) to update our build configurations.
-- A sync of the build image sha used in the [ci configuration](.circleci/config.yml) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/master/.circleci/config.yml) to sync our CI testing environment.
+- A sync of [.bazelrc](.bazelrc) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/main/.bazelrc) to update our build configurations.
+- A sync of the build image sha used in the [ci configuration](.circleci/config.yml) with [Envoy's version](https://github.com/envoyproxy/envoy/blob/main/.circleci/config.yml) to sync our CI testing environment.
 - Sometimes the dependency update comes with changes that break our build. We include any changes required to Nighthawk to fix that.

PROFILING.md

@@ -41,15 +41,15 @@ The interface served at localhost:8888 gives you various means to help with anal
 
 ### Envoy build
 
-See [building Envoy with Bazel](https://github.com/envoyproxy/envoy/tree/master/bazel#building-envoy-with-bazel).
+See [building Envoy with Bazel](https://github.com/envoyproxy/envoy/tree/main/bazel#building-envoy-with-bazel).
 
 Envoy’s static build is set up for profiling and can be build with:
 
 ```
 bazel build //source/exe:envoy-static
 ```
 
-More context: https://github.com/envoyproxy/envoy/blob/master/bazel/PPROF.md
+More context: https://github.com/envoyproxy/envoy/blob/main/bazel/PPROF.md
 
 ### Nighthawk build
 

README.md

@@ -15,7 +15,7 @@ Nighthawk currently offers:
 
 ### Ubuntu
 
-First, follow steps 1 and 2 over at [Quick start Bazel build for developers](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#quick-start-bazel-build-for-developers).
+First, follow steps 1 and 2 over at [Quick start Bazel build for developers](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#quick-start-bazel-build-for-developers).
 
 
 ## Building and using the Nighthawk client CLI
@@ -117,9 +117,9 @@ Nighthawk writes to the output. Default is false.
 
 --request-source-plugin-config <string>
 [Request
-Source](https://github.com/envoyproxy/nighthawk/blob/master/docs/root/
-overview.md#requestsource) plugin configuration in json or compact
-yaml. Mutually exclusive with --request-source. Example (json):
+Source](https://github.com/envoyproxy/nighthawk/blob/main/docs/root/ov
+erview.md#requestsource) plugin configuration in json or compact yaml.
+Mutually exclusive with --request-source. Example (json):
 {name:"nighthawk.stub-request-source-plugin"
 ,typed_config:{"@type":"type.googleapis.com/nighthawk.request_source.S
 tubPluginConfig",test_value:"3"}}

RELEASE_PROCEDURE.md

@@ -14,7 +14,7 @@
 
 ## Release steps
 
-1. Speculatively bump the version in [version_info.h](source/common/version_info.h) to the version you determined earlier. This may result in version gaps if a release attempt fails, but avoids having to freeze merges to master and/or having to work with release branches. In short it helps keeping the release procedure lean and mean and eliminates the need for blocking others while this procedure is in-flight.
+1. Speculatively bump the version in [version_info.h](source/common/version_info.h) to the version you determined earlier. This may result in version gaps if a release attempt fails, but avoids having to freeze merges to main and/or having to work with release branches. In short it helps keeping the release procedure lean and mean and eliminates the need for blocking others while this procedure is in-flight.
 2. Draft a [GitHub tagged release](https://github.com/envoyproxy/nighthawk/releases/new). Earlier releases are tagged like `v0.1`, but as of `0.3.0`we are using [semantic versioning](https://semver.org/spec/v2.0.0.html)
 3. Perform thorough testing of the targeted revision to double down on stability [1]
 4. Create an optimized build for comparing with the previous release. Changes in performance

api/adaptive_load/adaptive_load.proto

@@ -31,7 +31,7 @@ message AdaptiveLoadSessionSpec {
   // visualization. Optional.
   repeated MetricSpec informational_metric_specs = 3;
   // A proto describing Nighthawk Service traffic. See
-  // https://github.com/envoyproxy/nighthawk/blob/master/api/client/options.proto
+  // https://github.com/envoyproxy/nighthawk/blob/main/api/client/options.proto
   //
   // The adaptive load controller will return an error if the |duration| field is set within
   // |nighthawk_traffic_template|.

benchmarks/README.md

@@ -128,4 +128,4 @@ docker run -it --rm \
 - Have a mode where nighthawk_test_server provides high-res control timings in its
   access logs
 - The ability to repeat the runs multiple times and obtain stats, e.g. how much variance there is, mean, etc.
-- The ability to do A/B testing, similar to https://github.com/envoyproxy/envoy-perf/blob/master/siege/siege.py#L3.
+- The ability to do A/B testing, similar to https://github.com/envoyproxy/envoy-perf/blob/main/siege/siege.py#L3.

ci/docker/docker_push.sh

@@ -12,8 +12,8 @@ fi
 
 DOCKER_IMAGE_PREFIX="${DOCKER_IMAGE_PREFIX:-envoyproxy/nighthawk}"
 
-# push the nighthawk image on tags or merge to master
-if [[  "$CIRCLE_BRANCH" = 'master' ]]; then
+# push the nighthawk image on tags or merge to main
+if [[  "$CIRCLE_BRANCH" = 'main' ]]; then
     docker login -u "$DOCKERHUB_USERNAME" -p "$DOCKERHUB_PASSWORD"
     docker push "${DOCKER_IMAGE_PREFIX}-dev:latest"
     docker tag "${DOCKER_IMAGE_PREFIX}-dev:latest" "${DOCKER_IMAGE_PREFIX}-dev:${CIRCLE_SHA1}"
@@ -26,6 +26,6 @@ else
         docker tag "${DOCKER_IMAGE_PREFIX}:${TAG}" "${DOCKER_IMAGE_PREFIX}:${TAG}"
         docker push "${DOCKER_IMAGE_PREFIX}:${TAG}"
     else
-        echo 'Ignoring non-master branch for docker push.'
+        echo 'Ignoring non-main branch for docker push.'
     fi
 fi

docs/root/overview.md

@@ -58,7 +58,7 @@ back reports per phase.
 
 ## Key concept descriptions
 
-*The c++ interface definitions for the concepts below can be found [here](https://github.com/envoyproxy/nighthawk/tree/master/include/nighthawk)*.
+*The c++ interface definitions for the concepts below can be found [here](https://github.com/envoyproxy/nighthawk/tree/main/include/nighthawk)*.
 
 ### Process
 
@@ -195,5 +195,5 @@ Users of Nighthawk can specify custom format and destination (logging sink
 delegate) for all Nighthawk logging messages. Nighthawk utilizes the Envoy's
 logging mechanism by performing all logging via the **ENVOY_LOG** macro. To
 customize this mechanism, users need to perform two steps:
-1. Create a logging sink delegate inherited from [Envoy SinkDelegate](https://github.com/envoyproxy/envoy/blob/master/source/common/common/logger.h).
-2. Construct a ServiceImpl object with an [Envoy Logger Context](https://github.com/envoyproxy/envoy/blob/master/source/common/common/logger.h) which contains user-specified log level and format.
+1. Create a logging sink delegate inherited from [Envoy SinkDelegate](https://github.com/envoyproxy/envoy/blob/main/source/common/common/logger.h).
+2. Construct a ServiceImpl object with an [Envoy Logger Context](https://github.com/envoyproxy/envoy/blob/main/source/common/common/logger.h) which contains user-specified log level and format.

docs/root/statistics.md

@@ -61,7 +61,7 @@ histogram values are sent directly to the sinks. A stat
 is an interface that takes generic stat data and translates it into a
 backend-specific wire format. Currently Envoy supports the TCP and UDP
 [statsd](https://github.com/b/statsd_spec) protocol (implemented in
-[statsd.h](https://github.com/envoyproxy/envoy/blob/master/source/extensions/stat_sinks/common/statsd/statsd.h)).
+[statsd.h](https://github.com/envoyproxy/envoy/blob/main/source/extensions/stat_sinks/common/statsd/statsd.h)).
 Users can create their own Sink subclass to translate Envoy metrics into
 backend-specific format.	
 
@@ -90,7 +90,7 @@ stats.upstream_cx_length_.recordValue(...);
 Currently Envoy metrics don't support key-value map. As a result, for metrics to
 be broken down by certain dimensions, we need to define a separate metric for
 each dimension. For example, currently Nighthawk defines 
-[separate counters](https://github.com/envoyproxy/nighthawk/blob/master/source/client/benchmark_client_impl.h#L35-L40)
+[separate counters](https://github.com/envoyproxy/nighthawk/blob/main/source/client/benchmark_client_impl.h#L35-L40)
 to monitor the number of responses with corresponding response code.
 
 ## Envoy Metrics Flush	
@@ -128,7 +128,7 @@ key-value map.
 
 ## Reference	
 - [Nighthawk: architecture and key
-  concepts](https://github.com/envoyproxy/nighthawk/blob/master/docs/root/overview.md)	
+  concepts](https://github.com/envoyproxy/nighthawk/blob/main/docs/root/overview.md)	
 - [Envoy Stats
-  System](https://github.com/envoyproxy/envoy/blob/master/source/docs/stats.md)	
+  System](https://github.com/envoyproxy/envoy/blob/main/source/docs/stats.md)	
 - [Envoy Stats blog](https://blog.envoyproxy.io/envoy-stats-b65c7f363342)

extensions_build_config.bzl

@@ -1,4 +1,4 @@
-# See https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#disabling-extensions for details on how this system works.
+# See https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#disabling-extensions for details on how this system works.
 EXTENSIONS = {
     "envoy.filters.http.router": "//source/extensions/filters/http/router:config",
     "envoy.filters.http.fault": "//source/extensions/filters/http/fault:config",

source/client/options_impl.cc

@@ -270,7 +270,7 @@ OptionsImpl::OptionsImpl(int argc, const char* const* argv) {
   TCLAP::ValueArg<std::string> request_source_plugin_config(
       "", "request-source-plugin-config",
       "[Request "
-      "Source](https://github.com/envoyproxy/nighthawk/blob/master/docs/root/"
+      "Source](https://github.com/envoyproxy/nighthawk/blob/main/docs/root/"
       "overview.md#requestsource) plugin configuration in json or compact yaml. "
       "Mutually exclusive with --request-source. Example (json): "
       "{name:\"nighthawk.stub-request-source-plugin\",typed_config:{"

source/server/README.md

@@ -15,7 +15,7 @@ bazel build -c opt :nighthawk_test_server
 ```
 
 It is possible to
-[enable additional envoy extension](https://github.com/envoyproxy/envoy/blob/master/source/extensions/extensions_build_config.bzl) by adding them [here](../../extensions_build_config.bzl) before the build.
+[enable additional envoy extension](https://github.com/envoyproxy/envoy/blob/main/source/extensions/extensions_build_config.bzl) by adding them [here](../../extensions_build_config.bzl) before the build.
 By default, Nighthawk's test server is set up with the minimum extension set needed
 for it to operate as documented.