Cache hit errors while building envoy proxy in windows

[ssripadham]

Description of the bug:

Cache hits (race conditions) instead of downloading the corresponding file while building Envoy proxy

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

In the windows command shell

mkdir %USERPROFILE%\bazel
powershell Invoke-WebRequest https://github.com/bazelbuild/bazelisk/releases/latest/download/bazelisk-windows-amd64.exe -OutFile %USERPROFILE%\bazel\bazel.exe
set PATH=%USERPROFILE%\bazel;%PATH%

Configure, build and/or install the [Envoy dependencies]

Configure Visual Studio 2019
Build Tools for Visual Studio 2019: For building with MSVC, you must install at least the VC++ workload. You may alternately install the entire Visual Studio 2019 and use the Build Tools installed in that package. NOTE: ensure that the link.exe that resolves on your PATH is from VC++

BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio\2019\<>\VC
BAZEL_VC_FULL_VERSION=14.29.30133
BAZEL_WINSDK_FULL_VERSION=10.0.22621.0

Install bazelisk in the PATH using the bazel.exe executable name as described above in the first section.

Setup Envoy Proxy

git clone git@github.com:envoyproxy/envoy.git in C:

When building Envoy, Bazel creates very long path names. One way to work around these excessive path lengths is to change the output base directory for bazel to a very short root path.

An example Bazel configuration to help with this is to use C:_eb as the bazel base path. This and other preferences should be set up by placing the following bazelrc configuration line in the individual user's %USERPROFILE%.bazelrc file (rather than including it on every bazel command line):

startup  --windows_enable_symlinks  --output_base=C:/_eb --output_user_root=C:/tmp
build --enable_runfiles

Python
Specifically, the Windows-native flavor distributed by python.org. The POSIX flavor available via MSYS2, the Windows Store flavor and other distributions will not work. Add a symlink for python3.exe pointing to the installed python.exe for Envoy scripts and Bazel rules which follow POSIX python conventions. Add pip.exe to the PATH and install the wheel package.

mklink %USERPROFILE%\Python310\python3.exe %USERPROFILE%\Python39\python.exe
set PATH=%USERPROFILE%\Python310;%PATH%
set PATH=%USERPROFILE%\Python310\Scripts;%PATH%
pip install wheel

Build envoy

cd C:\envoy
bazel clean --expunge
bazel build //source/exe:envoy-static
or
bazel build -c opt envoy from the repository root.

Error:

  C:/_eb/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
  C:/_eb/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31: in <toplevel>
INFO: Repository 'com_github_google_quiche' used the following cache hits instead of downloading the corresponding file.
 * Hash 'e6f63b50a3ae05936638432ff70daad54044aecf86168a994a88c609f057ccb5' for https://github.com/google/quiche/archive/0e5ea736a587b096b3d615ba5c41ac3144704447.tar.gz
If the definition of 'com_github_google_quiche' was updated, verify that the hashes were also updated.
ERROR: An error occurred during the fetch of repository 'com_github_google_quiche':
   Traceback (most recent call last):
        File "C:/_eb/external/bazel_tools/tools/build_defs/repo/http.bzl", line 136, column 10, in _http_archive_impl
                patch(ctx, auth = auth)
        File "C:/_eb/external/bazel_tools/tools/build_defs/repo/utils.bzl", line 193, column 21, in patch
                fail("Error applying patch command %s:\n%s%s" %
Error in fail: Error applying patch command find quiche/ -type f -name "*.bazel" -delete:
FIND: Parameter format not correct
ERROR: C:/ws/envoy/WORKSPACE:13:19: fetching http_archive rule //external:com_github_google_quiche: Traceback (most recent call last):
        File "C:/_eb/external/bazel_tools/tools/build_defs/repo/http.bzl", line 136, column 10, in _http_archive_impl
                patch(ctx, auth = auth)
        File "C:/_eb/external/bazel_tools/tools/build_defs/repo/utils.bzl", line 193, column 21, in patch
                fail("Error applying patch command %s:\n%s%s" %

Which operating system are you running Bazel on?

Windows 11

What is the output of bazel info release?

release 6.0.0-pre.20220706.4

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

git@github.com:envoyproxy/envoy.git

git rev-parse main
486970135e3d520b5bdb6375af5f127701e5a8ae

486970135e3d520b5bdb6375af5f127701e5a8ae

Have you found anything relevant by searching the web?

Reference: https://docs.bazel.build/versions/main/windows.html
https://github.com/envoyproxy/envoy/blob/main/bazel/README.md
https://www.envoyproxy.io/docs/envoy/latest/start/building#windows-target-requirements

https://github.com/envoyproxy/envoy/blob/c3418f14daa6809ab47ce4c8d21ceceabbc7d292/bazel/README.md
envoyproxy/envoy#13194

Any other information, logs, or outputs that you want to share?

No response

[ssripadham]

Also followed https://bazel.build/configure/windows (Build C++ with MSVC and verified that this worked) meaning the setup itself is good.

[ssripadham]

Any update on this issue?

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[Aorimn]

Hi, I was affected by the same issue.

The "FIND: Parameter format not correct" looks like it's trying the FIND.exe binary instead of the MSYS2's find. For me, it was due to the PATH env where C:\msys64\usr\bin was after C:\Windows\system32.

This happened because of this note:

NOTE: ensure that the link.exe that resolves on your PATH is from VC++ Build Tools and not /usr/bin/link.exe from MSYS2

As the MSYS2 PATH modification step is after the VS one, I found the easiest way was to put MSYS2's path at the end of %PATH%.

The issue disappeared after I fixed this %PATH%