sync from master.

.azure-pipelines/cve_scan.yml

@@ -9,7 +9,7 @@ schedules:
   displayName: Hourly CVE scan
   branches:
     include:
-    - master
+    - main
   always: true
 
 pool:

.azure-pipelines/pipelines.yml

@@ -1,7 +1,7 @@
 trigger:
   branches:
     include:
-      - "master"
+      - "main"
       - "release/v*"
   tags:
     include:
@@ -54,6 +54,7 @@ stages:
           - script: ci/run_envoy_docker.sh 'ci/do_ci.sh docs'
             workingDirectory: $(Build.SourcesDirectory)
             env:
+              AZP_BRANCH: $(Build.SourceBranch)
               ENVOY_DOCKER_BUILD_DIR: $(Build.StagingDirectory)
               BAZEL_REMOTE_CACHE: grpcs://remotebuildexecution.googleapis.com
               BAZEL_REMOTE_INSTANCE: projects/envoy-ci/instances/default_instance
@@ -303,6 +304,7 @@ stages:
           - script: ci/run_envoy_docker.sh 'ci/do_ci.sh docs'
             workingDirectory: $(Build.SourcesDirectory)
             env:
+              AZP_BRANCH: $(Build.SourceBranch)
               ENVOY_DOCKER_BUILD_DIR: $(Build.StagingDirectory)
               BAZEL_REMOTE_CACHE: grpcs://remotebuildexecution.googleapis.com
               BAZEL_REMOTE_INSTANCE: projects/envoy-ci/instances/default_instance
@@ -321,7 +323,6 @@ stages:
             workingDirectory: $(Build.SourcesDirectory)
             env:
               AZP_BRANCH: $(Build.SourceBranch)
-              AZP_SHA1: $(Build.SourceVersion)
 
   - stage: verify
     dependsOn: ["docker"]
@@ -384,8 +385,13 @@ stages:
         pool:
           vmImage: "windows-latest"
         steps:
+          - task: Cache@2
+            inputs:
+              key: '"windows.release" | ./WORKSPACE | **/*.bzl'
+              path: $(Build.StagingDirectory)/repository_cache
+            continueOnError: true
           - bash: ci/run_envoy_docker.sh ci/windows_ci_steps.sh
-            displayName: "Run Windows CI"
+            displayName: "Run Windows msvc-cl CI"
             env:
               CI_TARGET: "windows"
               ENVOY_DOCKER_BUILD_DIR: "$(Build.StagingDirectory)"
@@ -409,6 +415,41 @@ stages:
               artifactName: windows.release
             condition: always()
 
+      - job: clang_cl
+        timeoutInMinutes: 120
+        pool:
+          vmImage: "windows-latest"
+        steps:
+          - task: Cache@2
+            inputs:
+              key: '"windows.release" | ./WORKSPACE | **/*.bzl'
+              path: $(Build.StagingDirectory)/repository_cache
+            continueOnError: true
+          - bash: ci/run_envoy_docker.sh ci/windows_ci_steps.sh
+            displayName: "Run Windows clang-cl CI"
+            env:
+              CI_TARGET: "windows"
+              ENVOY_DOCKER_BUILD_DIR: "$(Build.StagingDirectory)"
+              SLACK_TOKEN: $(SLACK_TOKEN)
+              REPO_URI: $(Build.Repository.Uri)
+              BUILD_URI: $(Build.BuildUri)
+              ENVOY_RBE: "true"
+              BAZEL_BUILD_EXTRA_OPTIONS: "--config=remote-ci --config=remote-clang-cl --jobs=$(RbeJobs) --flaky_test_attempts=2"
+              BAZEL_REMOTE_CACHE: grpcs://remotebuildexecution.googleapis.com
+              BAZEL_REMOTE_INSTANCE: projects/envoy-ci/instances/default_instance
+              GCP_SERVICE_ACCOUNT_KEY: $(GcpServiceAccountKey)
+          - task: PublishTestResults@2
+            inputs:
+              testResultsFiles: "**/bazel-out/**/testlogs/**/test.xml"
+              testRunTitle: "clang-cl"
+              searchFolder: $(Build.StagingDirectory)/tmp
+            condition: always()
+          - task: PublishBuildArtifacts@1
+            inputs:
+              pathtoPublish: "$(Build.StagingDirectory)/envoy"
+              artifactName: windows.clang-cl
+            condition: always()
+
       - job: docker
         dependsOn: ["release"]
         timeoutInMinutes: 120

.bazelrc

@@ -245,8 +245,8 @@ build:remote-clang-cl --config=clang-cl
 build:remote-clang-cl --config=rbe-toolchain-clang-cl
 
 # Docker sandbox
-# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/master/toolchains/rbe_toolchains_config.bzl#L8
-build:docker-sandbox --experimental_docker_image=envoyproxy/envoy-build-ubuntu:11efa5680d987fff33fde4af3cc5ece105015d04
+# NOTE: Update this from https://github.com/envoyproxy/envoy-build-tools/blob/main/toolchains/rbe_toolchains_config.bzl#L8
+build:docker-sandbox --experimental_docker_image=envoyproxy/envoy-build-ubuntu:c8fa4235714003ba0896287ee2f91cae06e0e407
 build:docker-sandbox --spawn_strategy=docker
 build:docker-sandbox --strategy=Javac=docker
 build:docker-sandbox --strategy=Closure=docker

.devcontainer/Dockerfile

@@ -1,4 +1,4 @@
-FROM gcr.io/envoy-ci/envoy-build:11efa5680d987fff33fde4af3cc5ece105015d04
+FROM gcr.io/envoy-ci/envoy-build:c8fa4235714003ba0896287ee2f91cae06e0e407
 
 ARG USERNAME=vscode
 ARG USER_UID=501

.github/ISSUE_TEMPLATE/non--crash-security--bug.md

@@ -22,7 +22,7 @@ returned, etc.
 > Include sample requests, environment, etc. All data and inputs
 required to reproduce the bug.
 
->**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/master/tools/envoy_collect/README.md)
+>**Note**: The [Envoy_collect tool](https://github.com/envoyproxy/envoy/blob/main/tools/envoy_collect/README.md)
 gathers a tarball with debug logs, config and the following admin
 endpoints: /stats, /clusters and /server_info. Please note if there are
 privacy concerns, sanitize the data prior to sharing the tarball/pasting.
@@ -46,4 +46,4 @@ sharing.
 
 *Call Stack*:
 > If the Envoy binary is crashing, a call stack is **required**.
-Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/master/bazel#stack-trace-symbol-resolution).
+Please refer to the [Bazel Stack trace documentation](https://github.com/envoyproxy/envoy/tree/main/bazel#stack-trace-symbol-resolution).

.github/workflows/get_build_targets.sh

@@ -6,7 +6,7 @@ readonly SEARCH_FOLDER="//source/common/..."
 set -e -o pipefail
 
 function get_targets() {
-  # Comparing the PR HEAD with the upstream master HEAD.
+  # Comparing the PR HEAD with the upstream main HEAD.
   git diff --name-only HEAD FETCH_HEAD | while IFS= read -r line
   do
     # Only targets under those folders.
@@ -23,6 +23,6 @@ function get_targets() {
 }
 
 # Fetching the upstream HEAD to compare with and stored in FETCH_HEAD.
-git fetch https://github.com/envoyproxy/envoy.git master 2>/dev/null
+git fetch https://github.com/envoyproxy/envoy.git main 2>/dev/null
 
 export BUILD_TARGETS_LOCAL=$(echo $(get_targets))

CODEOWNERS

@@ -160,3 +160,5 @@ extensions/filters/http/oauth2 @rgs1 @derekargueta @snowp
 /*/extensions/filters/common/local_ratelimit @mattklein123 @rgs1
 # HTTP Kill Request
 /*/extensions/filters/http/kill_request @qqustc @htuch
+# Rate limit expression descriptor
+/*/extensions/rate_limit_descriptors/expr @kyessenov @lizan

CONTRIBUTING.md

@@ -47,7 +47,7 @@ versioning guidelines:
 
 * Features may be marked as deprecated in a given versioned API at any point in time, but this may
   only be done when a replacement implementation and configuration path is available in Envoy on
-  master. Deprecators must implement a conversion from the deprecated configuration to the latest
+  main. Deprecators must implement a conversion from the deprecated configuration to the latest
   `vNalpha` (with the deprecated field) that Envoy uses internally. A field may be deprecated if
   this tool would be able to perform the conversion. For example, removing a field to describe
   HTTP/2 window settings is valid if a more comprehensive HTTP/2 protocol options field is being
@@ -73,7 +73,7 @@ versioning guidelines:
   `envoy.features.enable_all_deprecated_features` is set to true. Finally, following the deprecation
   of the API major version where the field was first marked deprecated, the entire implementation
   code will be removed from the Envoy implementation.
-* This policy means that organizations deploying master should have some time to get ready for
+* This policy means that organizations deploying main should have some time to get ready for
   breaking changes at the next major API version. This is typically a window of at least 12 months
   or until the organization moves to the next major API version.
 * The breaking change policy also applies to source level extensions (e.g., filters). Code that
@@ -99,7 +99,7 @@ versioning guidelines:
 
   Please see [support/README.md](support/README.md) for more information on these hooks.
 
-* Create your PR.
+* Create your PR. If your PR adds new code, it should include tests [covering](source/docs/coverage.md) the new code.
 * Tests will automatically run for you.
 * We will **not** merge any PR that is not passing tests.
 * PRs are expected to have 100% test coverage for added code. This can be verified with a coverage
@@ -144,7 +144,7 @@ versioning guidelines:
 * If your PR involves any changes to
   [envoy-filter-example](https://github.com/envoyproxy/envoy-filter-example) (for example making a new
   branch so that CI can pass) it is your responsibility to follow through with merging those
-  changes back to master once the CI dance is done.
+  changes back to main once the CI dance is done.
 * If your PR is a high risk change, the reviewer may ask that you runtime guard
   it. See the section on runtime guarding below.
 
@@ -189,18 +189,18 @@ maintainer's discretion. Generally all runtime guarded features will be set true
 release is cut. Old code paths for refactors can be cleaned up after a release and there has been
 some production run time. Old code for behavioral changes will be deprecated after six months.
 Runtime features are set true by default by inclusion in
-[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/master/source/common/runtime/runtime_features.cc)
+[source/common/runtime/runtime_features.cc](https://github.com/envoyproxy/envoy/blob/main/source/common/runtime/runtime_features.cc)
 
 There are four suggested options for testing new runtime features:
 
-1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/master/test/common/protobuf/utility_test.cc)
+1. Create a per-test Runtime::LoaderSingleton as done in [DeprecatedFieldsTest.IndividualFieldDisallowedWithRuntimeOverride](https://github.com/envoyproxy/envoy/blob/main/test/common/protobuf/utility_test.cc)
 2. Create a [parameterized test](https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#how-to-write-value-parameterized-tests)
    where the set up of the test sets the new runtime value explicitly to
    GetParam() as outlined in (1).
 3. Set up integration tests with custom runtime defaults as documented in the
-   [integration test README](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md)
+   [integration test README](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md)
 4. Run a given unit test with the new runtime value explicitly set true or false as done
-   for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/master/test/common/runtime/BUILD)
+   for [runtime_flag_override_test](https://github.com/envoyproxy/envoy/blob/main/test/common/runtime/BUILD)
 
 Runtime code is held to the same standard as regular Envoy code, so both the old
 path and the new should have 100% coverage both with the feature defaulting true
@@ -233,6 +233,13 @@ and false.
 * If a PR includes a deprecation/breaking change, notification should be sent to the
   [envoy-announce](https://groups.google.com/forum/#!forum/envoy-announce) email list.
 
+# API changes
+
+If you change anything in the [api tree](https://github.com/envoyproxy/envoy/tree/master/api),
+please read the [API Review
+Checklist](https://github.com/envoyproxy/envoy/tree/master/api/review_checklist.md)
+and make sure that your changes have addressed all of the considerations listed there.
+
 # Adding new extensions
 
 For developers adding a new extension, one can take an existing extension as the starting point.

DEPENDENCY_POLICY.md

@@ -40,7 +40,7 @@ Dependency declarations must:
   and `urls` to reference the version. If you need to reference version `X.Y.Z` as `X_Y_Z`, this
   may appear in a string as `{underscore_version}`, similarly for `X-Y-Z` you can use
   `{dash_version}`.
-* Versions should prefer release versions over master branch GitHub SHA tarballs. A comment is
+* Versions should prefer release versions over main branch GitHub SHA tarballs. A comment is
   necessary if the latter is used. This comment should contain the reason that a non-release
   version is being used.
 * Provide accurate entries for `use_category`. Please think carefully about whether there are data
@@ -112,7 +112,7 @@ basis:
 
 * Extension [CODEOWNERS](CODEOWNERS) should update extension specific dependencies.
 
-Where possible, we prefer the latest release version for external dependencies, rather than master
+Where possible, we prefer the latest release version for external dependencies, rather than main
 branch GitHub SHA tarballs.
 
 ## Dependency shepherds

DEVELOPER.md

@@ -1,38 +1,38 @@
 # Developer documentation
 
 Envoy is built using the Bazel build system. Our CI on Azure Pipelines builds, tests, and runs coverage against
-all pull requests and the master branch.
+all pull requests and the main branch.
 
-To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#quick-start-bazel-build-for-developers).
-To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#testing-envoy-with-bazel) for Google Test.
-To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md#coverage-builds).
+To get started building Envoy locally, see the [Bazel quick start](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#quick-start-bazel-build-for-developers).
+To run tests, there are Bazel [targets](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#testing-envoy-with-bazel) for Google Test.
+To generate a coverage report, there is a [coverage build script](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#coverage-builds).
 
-If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/master/support/README.md), which helps automate parts of the development process, particularly those involving code review.
+If you plan to contribute to Envoy, you may find it useful to install the Envoy [development support toolchain](https://github.com/envoyproxy/envoy/blob/main/support/README.md), which helps automate parts of the development process, particularly those involving code review.
 
 Below is a list of additional documentation to aid the development process:
 
 - [General build and installation documentation](https://www.envoyproxy.io/docs/envoy/latest/start/start)
 
-- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/README.md)
+- [Building and testing Envoy with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/README.md)
 
-- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/master/bazel/EXTERNAL_DEPS.md)
+- [Managing external dependencies with Bazel](https://github.com/envoyproxy/envoy/blob/main/bazel/EXTERNAL_DEPS.md)
 
-- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/master/bazel/DEVELOPER.md)
+- [Guide to Envoy Bazel rules (managing `BUILD` files)](https://github.com/envoyproxy/envoy/blob/main/bazel/DEVELOPER.md)
 
-- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/master/ci)
+- [Using Docker for building and testing](https://github.com/envoyproxy/envoy/tree/main/ci)
 
-- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/master/CONTRIBUTING.md)
+- [Guide to contributing to Envoy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md)
 
-- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/master/test/README.md)
+- [Overview of Envoy's testing frameworks](https://github.com/envoyproxy/envoy/blob/main/test/README.md)
 
-- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md)
+- [Overview of how to write integration tests for new code](https://github.com/envoyproxy/envoy/blob/main/test/integration/README.md)
 
 - [Envoy filter example project (how to consume and extend Envoy as a submodule)](https://github.com/envoyproxy/envoy-filter-example)
 
-- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/master/bazel/PPROF.md)
+- [Performance testing Envoy with `tcmalloc`/`pprof`](https://github.com/envoyproxy/envoy/blob/main/bazel/PPROF.md)
 
 And some documents on components of Envoy architecture:
 
-- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/master/source/docs/flow_control.md)
+- [Envoy flow control](https://github.com/envoyproxy/envoy/blob/main/source/docs/flow_control.md)
 
-- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/master/source/docs/subset_load_balancer.md)
+- [Envoy's subset load balancer](https://github.com/envoyproxy/envoy/blob/main/source/docs/subset_load_balancer.md)

EXTENSION_POLICY.md

@@ -15,7 +15,7 @@ The following procedure will be used when proposing new extensions for inclusion
   2. All extensions must be sponsored by an existing maintainer. Sponsorship means that the
   maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor
   extensions if they are going to write them, shepherd them, and maintain them.
-  
+
      Sponsorship serves two purposes:
      * It ensures that the extension will ultimately meet the Envoy quality bar.
      * It makes sure that incentives are aligned and that extensions are not added to the repo without
@@ -24,7 +24,7 @@ The following procedure will be used when proposing new extensions for inclusion
      *If sponsorship cannot be found from an existing maintainer, an organization can consider
      [doing the work to become a maintainer](./GOVERNANCE.md#process-for-becoming-a-maintainer) in
      order to be able to self-sponsor extensions.*
-  
+
   3. Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of
   the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other
   contributors can count towards this number. The initial reviewers will be codified in the
@@ -105,7 +105,7 @@ The `security_posture` is one of:
 * `unknown`: This is functionally equivalent to `requires_trusted_downstream_and_upstream`, but acts
   as a placeholder to allow us to identify extensions that need classifying.
 * `data_plane_agnostic`: Not relevant to data plane threats, e.g. stats sinks.
- 
+
 An assessment of a robust security posture for an extension is subject to the following guidelines:
 
 * Does the extension have fuzz coverage? If it's only receiving fuzzing
@@ -122,7 +122,7 @@ An assessment of a robust security posture for an extension is subject to the fo
 * Does the extension have active [CODEOWNERS](CODEOWNERS) who are willing to
   vouch for the robustness of the extension?
 * Is the extension absent a [low coverage
-  exception](https://github.com/envoyproxy/envoy/blob/master/test/per_file_coverage.sh#L5)?
+  exception](https://github.com/envoyproxy/envoy/blob/main/test/per_file_coverage.sh#L5)?
 
 The current stability and security posture of all extensions can be seen
 [here](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/threat_model#core-and-extensions).