Support the Bazel build system about ort HOT 22 OPEN

As per @alexeagle who I've met at PackageCon, something like bazel query --output=streamed_jsonproto '//external:*' should get us going.

from ort.

I've been looking into this for a few days now. To keep things simple I created two repositories with toy examples that use Bazel:

1. workspace flavor
2. bzlmod flavor

Since Bazel is at the tail end of switching to bzlmod by now, it makes sense to focus on the second one first.

Both repositories contain a Python program, a C++ program and an Android app. The latter consists of a library and an Activity that consumes the library. The Android app is from the Bazel Android tutorial. I just added OkHttp as an external dependency. The Python and C++ programs also have one external dependency each, which both have dependencies as well (at least in the bzlmod case).

Unlike Bazel itself, bzlmod is an actual package manager that uses a well-known location in a well-known format to retrieve metadata, source and binary artifacts of dependencies. For projects that actually use bzlmod to manage dependencies, implementing "Bazel support" looks to be relatively straightforward.

However, before one can do that, the first challenge is to determine what build targets a given code base contains. A promising approach seems to be looking for BUILD and BUILD.bazel files and running an appropriate bazel query command that will output what rule is used (e.g. android_binary) and the label of the build target (the string that goes after bazel build, e.g. //src/main:app). An example from the android directory in the above linked bzlmod repo:

$ bazel query 'kind(".*_binary|.*_library|._test", //...)' --output=location
/Users/haiko/code/act/bazel-android-py-cc-bzlmod/android/src/main/BUILD:1:15: android_binary rule //src/main:app
/Users/haiko/code/act/bazel-android-py-cc-bzlmod/android/src/main/java/com/example/bazel/BUILD:5:16: android_library rule //src/main/java/com/example/bazel:greeter_activity

The C++ program in the same repo uses bzlmod to pull in glog and its' dependencies. Running bazel mod graph --output json in the cc directory produces a delightfully simple JSON-formatted dependency graph. The fact that the Bazel Central Registry is used to fetch metadata about these dependencies can probably be teased out with the right bazel subcommand. If not, it is at least recorded somewhere in cc/MODULE.bazel.lock:

$ grep bcr.bazel.build MODULE.bazel.lock
      "https://bcr.bazel.build/"
            "https://bcr.bazel.build/modules/glog/0.5.0/patches/remove_only_the_first_leading_at.patch": "sha256-ieceuBwB5MiGzs1ES3FKKLTCuHwxxERo2clZn5h8S3g=",
    [...]

Looking at https://bcr.bazel.build or rather the Github repo it points to, we find a handy-dandy
sources.json which seems to contain everything necessary to retrieve the source code that goes into the build. Ka-ching!

That concludes the "good news" part. The bad news is that for the vast majority of projects that do not use C or C++, it seems highly unlikely that they will abandon pip/poetry, Maven, npm, etc. in favor bzlmod. So in practice there does not seem to be much difference between the workspace and the bzlmod world for these projects. Maybe the semi-good part about this is that existing functionality in ORT can be used to cover them, but how exactly that would work is still a bit blurry to me and most likely requires custom code for any type of programming language/ecosystem that needs to be supported. The first challenge here is to identify what exactly is being used to manage dependencies and what the relevant manifest/lock/etc. files are to process.

I had a reasonably fruitful conversation with ChatGPT about this subject. Of course, it could be wrong and there could be a better approach. But so far
I haven't been able to find that by reading Bazel documentation or code.

from ort.

Yes, we've always needed an abstraction layer so that tooling like this (SBOM generation, license compliance checks) can "read-through" the Bazel graph to the third-party dependencies for every language. Most languages (C++ being the notable exception) are implemented on top of a native package manager rather than throw it away. I can give you some pointers on this, I just connected with folks at https://www.endorlabs.com/blog/introducing-a-better-way-to-sca-for-monorepos-and-bazel who might share some of what they did.

from ort.

To double-check, probably a comparison to the results of https://github.com/snyk-labs/bazel2snyk makes sense, @haikoschol.

from ort.

Quote from the repo-discuss group:

Bazel doesn't offer any built in feature to resolve transitive Maven dependency.

from ort.

Already since a while now, Bazel has a repository rule to resolve and fetch Maven artifacts transitively.

Also, Bazel reached the 1.0 milestone recently.

from ort.

There are plan to improve Bazel's legacy support for license-checking third party dependencies, which is maybe something we could make use of.

from ort.

Bazel team is improving license checking see this document and seem they also have some tools in https://github.com/bazelbuild/rules_license.

There is some interest from the HERE side to develop support in ORT for Bazel so listing our standard requirements questions:

1. How can a tool detect that a project is using Bazel? Are the specific project definition or lock files?
2. How to can one obtain dependency tree including package names, versions, declared license, code repository and binary artifact?
3. How can one obtain the source for used package/dependency?
4. Is it possible to separate package into different scopes e.g. used only for building/testing the code?
5. Which public Bazel project or projects should we use to develop and test Bazel support in ORT?

from ort.

How can a tool detect that a project is using Bazel? Are the specific project definition or lock files?

Each project using bazel contains a file called "WORKSPACE" at the toplevel. I think that's the easiest way to check.

How to can one obtain dependency tree including package names, versions, declared license, code repository and binary artifact?

Through bazel cquery one can get the dependency tree and package names.
https://docs.bazel.build/versions/master/cquery.html
If https://github.com/bazelbuild/rules_license produces queriable rules, it might be possible to filter them out via cquery, but I have not tried.

How can one obtain the source for used package/dependency?

https://docs.bazel.build/versions/master/external.html

These are listed in the WORKSPACE file; they should also be queriable via cquery. All of them are hashed for reproducible builds.

Is it possible to separate package into different scopes e.g. used only for building/testing the code?

Yes.

Which public Bazel project or projects should we use to develop and test Bazel support in ORT?

My advice: Gerrit or or Bazel itself. There are others, but these should be relatively stable and well tested to begin with. (Most software at Google nowadays uses Bazel to build, e.g. Android stuff too).

from ort.

As since yesterday, on BazelCon, they had a session on upcoming bzlmod, which is the Bazel package Manager, intended to be integrates on Bazel 5.0.
Here's the design document:
https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit

Few key points:

• Originally was a independent tool, will be integrated in main bazel tool on version 5.0 ( LTS )
• Has two operation modes, an own registry for bazel packages itself, a extended plugin for act as a bridge to external package managers ( a.k.a. Maven )
• Still doesn't have a clear solution for C/C++ Packaging

from ort.

Thanks for the update. A super-important topic for ORT would be if that new system would allow to only query the transitive dependency tree incl. metadata, without actually building the project or even downloading the build artifacts (like Maven can do). Do you have any information on whether that's possible?

from ort.

https://github.com/vmware/rules_oss_audit uses Bazel inspect to analyze the dependency graph of a build and collect license information about each package it finds.

from ort.

Yep, all the process is done without building.
Still, Bazel 5.0 was just releasead and tool is still on the experimental flag, so we keep noticing, but i still thinking is not in the final format.

from ort.

@tsteenbe Yes, but in the case of vmware, they got the the dependencies explicitly already coming from RPM, so inspect works in some cases, but then, all the metadata comes from the RPM specfile itself.

from ort.

Note to myself: There's a Codelab for Bazel.

from ort.

This session from BazelCon 2021 might also be interesting: Solving the complexities of identifying and tracking open-source software (OSS) to comply with license requirements by using Bazel to create an accurate bill of materials containing OSS and third-party packages during a build.

from ort.

Also see the Bazel Central Registry.

from ort.

By now we're at Bazel 6.0 LTS which features Bzlmod.

from ort.

We should be aiming for C++, Java / Android and Python support via Bazel to start with.

from ort.

A reference that could become useful: https://github.com/vmware/rules_oss_audit

from ort.

folks at https://www.endorlabs.com/blog/introducing-a-better-way-to-sca-for-monorepos-and-bazel who might share some of what they did.

That would be useful, thanks @alexeagle!

from ort.

To double-check, probably a comparison to the results of https://github.com/snyk-labs/bazel2snyk makes sense, @haikoschol.

This tool examines Bazel build targets. That was also my initial intuition, but it turned out to be possible to gather the information the Analyzer is supposed to produce without doing so.

If we wanted to change the approach in the Bazel package manager plugin, the main question would be how build targets fit into the ORT domain model.

from ort.