Add googletest Bazel dep

[DominikAFischer]

Add googletest Bazel dep

The vendored googletest v1.12.1 instance at libs/3rparty/googletest is incompatible with newer Bazel versions.
Instead we include the equivalent version from the google central registry as a Bazel dep directly.

[christian-schilling]

I don't think this is a good idea.
We vendor for a reason and there must be a way to make bazel work with a vendored googletest.
On top of that, see: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/

[christophruethingbmw]

By which mean is the checked-in version in libs/3rdparty incopatible with bazel? It is just a copy of the official https://github.com/google/googletest.git right? Until now we do not yet have any usage of googletest?

Regarding mutable references: I think since we have checked in the MODULE.bazel.lock we are save in a sense that we pin to the explicit hashes stored in there. Of course in the end it depends on whether we have validated that whatever we now have pinned is also "okay".

[DominikAFischer]

Thank you for the input @christian-schilling

I don't think this is a good idea.

Can you elaborate why you think that it is not a good idea? There's a few alternative solutions but depending on the "why" some of them won't make sense either. The problem is that the old (four years old) googletest instance is just not compatible with newer Bazel versions (WORKSPACE vs BAZLEMOD configuration systems).

If you dislike pulling in a Bazel dependency via the official Bazel Central Registry (BCR), we can apply the patch manually in the vendored instance.
Just to be clear: this will also cause other Bazel deps being pulled in via the BCR transitively:

• bazel_dep(name = "abseil-cpp", repo_name = "com_google_absl", version = "20210324.2")
• bazel_dep(name = "platforms", version = "0.0.5")
• bazel_dep(name = "rules_cc", version = "0.0.1")
  ⠀
  ⠀

On top of that, see: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/

As Christoph mentioned, the mutable-reference window exists only until the lockfile is updated. After I ran bazel mod deps --lockfile_mode=update the lockfile contains all artefacts' hashes and we should be fully content-addressed.
That's essentially the same model as Cargo's Cargo.lock system, no?

[DominikAFischer]

Bonus question:
⠀
Is there a specific reason why we use this ancient googletest version? Is it due to compatibility with C++11?
Maybe there's even also security considerations for that?

[christophruethingbmw]

In case the incompatability is due to the old googletest version, why not update it? In case also a newer version works I personally would be happy to be more up-to-date :) Of course, we need to consider the C++ versions we want to support, but I think minimal C++ agreed for OpenBSW is anyway C++14. So we could update to 1.16.x at least.

[DominikAFischer]

As Christoph suggested it seems we can also remove the transitive depedencies from the googltest patch and it still seems to work. We can do that if the priority is to avoid using the bazel_dep system. This is then totally untested of course and we're diverging from the official solution.

[christian-schilling]

Thank you for the input @christian-schilling

I don't think this is a good idea.

Can you elaborate why you think that it is not a good idea?

Yes. So I think which each external single point of failure we are adding to the build we are cumulatively making the build less reliable especially when considering the long term.
Yes the bazel registry might be somewhat reliable now. But in 10 years? 20 years? Google might decide to stop supporting it.
Nobody saw github collapse 10 years ago, now we are watching it fall apart...
I had a similar discussion about using crates.io recently.

As much as possible the build should be able to run with network completely disabled. That's much more secure and also more reliable.

So I strongly suggest treating every reliance on any external infrastructure as a liability that needs to offer massive value to make up for the long term risks it introduces. I don't see that here. Not even close.

Also: I understand correctly with this change the bzl and cmake builds would use different googletest sources? That does not sound very desirable either.

If you dislike pulling in a Bazel dependency via the official Bazel Central Registry (BCR), we can apply the patch manually in the vendored instance. Just to be clear: this will also cause other Bazel deps being pulled in via the BCR transitively:

• bazel_dep(name = "abseil-cpp", repo_name = "com_google_absl", version = "20210324.2")
• bazel_dep(name = "platforms", version = "0.0.5")
• bazel_dep(name = "rules_cc", version = "0.0.1")
  ⠀

Of course that all also applies to transitive dependencies. A good way to test this would be to actually build in containers with --network=none.

There's a few alternative solutions but depending on the "why" some of them won't make sense either. The problem is that the old (four years old) googletest instance is just not compatible with newer Bazel versions (WORKSPACE vs BAZLEMOD configuration systems).

⠀

On top of that, see: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/

As Christoph mentioned, the mutable-reference window exists only until the lockfile is updated. After I ran bazel mod deps --lockfile_mode=update the lockfile contains all artefacts' hashes and we should be fully content-addressed. That's essentially the same model as Cargo's Cargo.lock system, no?

Lockfile is of course better than just tags. Didn't know about that.

[christian-schilling]

In case the incompatability is due to the old googletest version, why not update it? In case also a newer version works I personally would be happy to be more up-to-date :) Of course, we need to consider the C++ versions we want to support, but I think minimal C++ agreed for OpenBSW is anyway C++14. So we could update to 1.16.x at least.

+1 for updating (if possible)

[christophruethingbmw]

My proposal would be for now:

• We stick with the checked-in version of google test for now and integrated it as we also integrate the other third party libraries we have into bazel. Especially to avoid having a different version in bazel and cmake build. In case we decide to switch to bazel all toghether we can think of whether we have other mechanisms in bazel to gather external dependencies fulfilling all of our needs.

• In case it helps, we can update to the latest google test version that helps for us. In case we do not need it for this PR, we should in my opinion do it in any case separately.

[christian-schilling]

My proposal would be for now:

• We stick with the checked-in version of google test for now and integrated it as we also integrate the other third party libraries we have into bazel. Especially to avoid having a different version in bazel and cmake build. In case we decide to switch to bazel all toghether we can think of whether we have other mechanisms in bazel to gather external dependencies fulfilling all of our needs.
• In case it helps, we can update to the latest google test version that helps for us. In case we do not need it for this PR, we should in my opinion do it in any case separately.

Agreed 👍🏻