bazel: copy .bazelversion for envoy filter examples

[keith]

This file needs to be copied otherwise bazelisk picks whichever current
version is out there which could break with any release

Signed-off-by: Keith Smiley keithbsmiley@gmail.com

[phlax]

cc @lizan

[keith]

oh it's more complicated than this. that repo has a symlink to bazelversion from the submodule of envoy https://github.com/envoyproxy/envoy-filter-example/blob/main/.bazelversion

Interesting circular dependency for updating it since the tests here rely on that. I removed that version here now, which might work, but that doesn't feel right either if it actually does reference bazel files from the submodule

[phlax]

Interesting circular dependency for updating it since the tests...

this seems to be a bit of an endemic problem

ideally using a third party repo - ie envoy-build-tools should resolve and provide an authoritative version, but atm we seem to be just adding more places where versions are specified

im wondering if there is some automation/validation we can add in consuming CI to ensure that there is only one place where version/s need to be specified, and consumers check/copy/enforce versions from whereever we decide is authoritative (<-- as a general approach that we do more often)

[phlax]

(i guess this PR is ~doing what i suggested, but this kinda problem seems to happen with quite a few deps)

[keith]

yea, I could still see this having issues if that repo actually references bazel files from the submodule, if they also had to be updated to be compatible

[phlax]

if they also had to be updated to be compatible

hmm, yep https://github.com/envoyproxy/envoy-filter-example doesnt seem to have much in the way of CI and/or i guess pinning to version/s

[phlax]

/retest

[repokitteh-read-only]

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #18730 (comment) was created by @phlax.

see: more, trace.