Bazel Build technical debt

[cgv-wd]

What happened?

Bazel build documentation outdated and unable to build dotnet sources using Bazel on Windows.

Steps like correctly setting up VCTools and MSBuild environment variables are unclear and there are either missing requirements or unclear specifications for portions of the Bazel build instructions. From what I understood after looking around for support on this topic it looks like this has been a long standing issue, as mention by @jimevans, due to a combination of factors:

If you try building using bazel build //dotnet/…, you’re going to have a Bad Time™. The rule set used to build the .NET bindings is not the “official” Bazel .NET rules, because those rules make some assumptions that run counter to how .NET environments like to build. This is particularly so with multiple framework versions encompassing .NET Framewotk, .NET Core, and the subsequent unification of those with .NET 5 and beyond..

The ones we do use, are much better in that regard, but they’re also wildly incomplete, mostly in the execution of stuff using bazel test or bazel run. We attempt to use some custom rules in those cases, but they’re, frankly speaking, poorly written.

The custom rules’ author (me) doesn’t know what he’s doing when constructing Bazel rules, and no one with any real expertise in writing Bazel rules seems to have any interest in donating effort to make them actually work. Those same people with the proper Bazel skill set also usually have no understanding of the peculiarities of .NET projects, or the know how to make them to work seamlessly on Windows.

• Originally posted by @jimevans in https://github.com/SeleniumHQ/selenium/issues/9915#issuecomment-944896131

---

I recently went through all of the steps in the documentation for a fresh setup, using the linked blog article for WIndows as a reference as well, and after spending a few hours trying to resolve it I was still ultimately unsuccessful in building even the dotnet project via VS command line.

Note: Building just the WebDriver, WebDriver.Support, and WebDriverBackedSelenium dotnet projects from within Visual Studio 2019 works and successfully builds the DLLs for each .NET standard and framework. Building the tests is a different story...

We should potentially consider moving away from the Bazel implementation for complete building via command line.

How can we reproduce the issue?

• On latest Windows 10 with latest Visual Studio 2019 and Visual Studio Command Line Tools installed, follow all of the documented steps for setting up the Bazel build environment
• You may need to use the linked blog article for assistance with some of the steps
• Run command to build dotnet using Bazel: bazel build //dotnet/

Operating System

Windows 10 v19044.1586

Selenium version

Fresh checkout of Selenium 4 trunk

[github-actions[bot]]

@cgv-wd, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[AutomatedTester]

thanks for the issue. This is a major blind spot for the team and could definitely do better.

[jimevans]

Unfortunately, moving away from the Bazel implementation is a non-starter. There are parts of the .NET bindings that are written in languages other than C#. As an example, see the automation atoms included as resources in the built assemblies that are loaded and executed at runtime, which are JavaScript, and which the build system "compiles" and minifies to reduce the traffic sent across the wire.

I'm open to discussing areas where the existing build is failing and seeing where we can collaborate to smooth out those rough edges, but the Selenium project requires a cross-language build tool. Over the years, we've taken several approaches from writing our own (entirely unmaintainable) custom cross-language declarative build system; used Buck, which had shortcomings that could not be overcome when the product team rearchitected, and now moved to Bazel. As mentioned in the issue linked to and so thoughtfully quoted in the issue report, the Bazel ecosystem does not play nicely with the way .NET sees the projects it builds. Custom rules are needed to accomplish most things that need to be done in Bazel with .NET-based code, and those, like any other technical skill, require investment and practice. The .NET maintainers do not have the bandwidth to develop that set of technical skills to the level where it becomes "easy" to implement.

[github-actions[bot]]

This issue is looking for contributors.

Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.

[titusfortner]

@shs96c fyi looks like we have this ticket for tracking some of the .NET Bazel issues we've discussed.

[titusfortner]

Hey @purkhusid — shot in the dark here, but do you have time to discuss the official dotnet bazel rules with us?

We are using https://github.com/Brightspace/rules_csharp right now, and I see that you merged functionality from it into bazelbuild/rules_dotnet. The person who implemented this for us is taking a break from the code for a while, but we are interested in migrating and would like to talk about it. We can be reached via Slack/Matric/IRC with #selenium-tlc or email us: [email protected]

Thanks!

[nvborisenko]

Why not just dotnet build, or dotnet pack, or dotnet test. It is easy. Solution: keep preconditions for building as artifacts (couple of js files, cdp auto-generated classes). That's all what is required to make dev experience in .net absolutely comfortable.

Keeping generated pre-requisites under git allows to:

• not install huge number of software
• not waste time to build pre-requisites again and again
• increase speed of build process
• involve more contributors
• clean up repo and removing some strange binaries like third_party/dotnet/** (nuget.exe is there, hmmm)
• be independent of unnecessary build party who is show stopper in very simple cases: https://github.com/bazelbuild/rules_dotnet/issues/343

How I see new process: all bindings (most likely) require common prerequisites. CI process tracks original source, and generate artifacts once original source has been changed - and pushes to repo, which initiates testing stage for all dependent bindings.

Final remark for everybody here: you can remove *.csproj files, they are not a part of building process. Ah, CI uses dotnet test cli command (interesting why not bazel). Hm, and selenium-manager.exe (pre-requisite) is under git. Philosophy is not kept up.

[titusfortner]

@nvborisenko This issue is about how to address our Bazel issues, not whether to use Bazel in the first place.

How about this: If there is anything you think should be done differently, open a new issue for it. We'll try to put pros and cons on there and we can record a decision and whether or not we want to revisit in the future. Then we can have something to reference whenever anyone has the same concern and we can avoid regularly discussing things in a way that can be aggravating to some.

[titusfortner]

1. I have updated the Readme for Installing on Windows
2. We've improved the bazel implementation for .NET considerably, so the build can happen on the command line. There are many more things to do, but I don't think this is the right issue to track them in.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.