Conversation
Signed-off-by: Simon Scatton <sscatton@nvidia.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
| practical hermeticity through declared inputs, pinned toolchains, and isolated | ||
| actions. | ||
|
|
||
| Bazel's complexity is the strongest argument against adoption, and the purpose |
There was a problem hiding this comment.
It might be good to explain what complexity is being referred to here; a lot of historical complexity in Bazel has been removed e.g. through tooling like Bzlmod. We should make sure our assessment of Bazel is grounded in the experience today, not an experience someone may have had years ago.
| actions. | ||
|
|
||
| Bazel's complexity is the strongest argument against adoption, and the purpose | ||
| of this RFC is to decide whether its benefits justify that cost for OpenShell. |
There was a problem hiding this comment.
Similarly, explain what the actual cost of adopting Bazel is in concrete terms as it relates to complexity or otherwise.
|
|
||
| Bazel's complexity is the strongest argument against adoption, and the purpose | ||
| of this RFC is to decide whether its benefits justify that cost for OpenShell. | ||
| If accepted, the migration would keep the existing Cargo and Mise workflows |
There was a problem hiding this comment.
+1 to @krishicks. The historical concerns with Bazel were non-hermetic behavior due to actions downloading pre-compiled binaries, manual dependency mirroring, and the issues of maintaining reproducible builds However, modern Bazel (9+) with Bzlmod addresses the core hermeticity issues through proper module resolution and dependency pinning.
From productization and downstream perspective of RH, we are fine with Bazel, provided we are considering latest Bazel + bazelmod. As of now, we have setup pipelines with cargo workflows from main, and can transition to Bazel if there is sufficient overlap in time
Supporting document for #2491