Bazel Module

[borg286]

Feature Description

Problem Statement:
Make a GitOps-style release pipeline spanning code of binary out to full stack in k8s

Proposed Solution:
Make a BzlMod module in the style of https://github.com/bazelbuild/rules_k8s (deprecated) and https://github.com/abrisco/rules_helm/tree/0.10.0
(helm-specific but works with bzlmod) where users have bazel build targets that either produce the leaf nodes of the DAG, or outputs the full RGD itself. All docker images referenced are also called out as bazel dependencies. When the target gets executed the dependent images get build (relying on bazel's native ability to recurse and build binaries), use the sha256 of the image, replace image references with one that locks in the sha256 tag, uploads the docker image, then pushes the yaml to k8s.

With such a module one could theoretically do a bazel run //my/target:rgd.apply
and bazel would detect any changes in any of the images in the rgd, rebuild the binaries using it's impressive caching, upload the image (recall docker only needs the layers that changed, so only final layer containing the binary would need to be uploaded), and the rgd yaml would get regenerated (with the image sha256 getting updated), then applied to k8s with only the leaf nodes in the DAG having anything to apply, then k8s would perform rollouts on just those leaf nodes. The above bazel run could get executed every minute with almost no computations needing to be done thanks to both bazel, the docker repo and k8s recognizing how little actually changed.

Alternatives Considered:
https://github.com/abrisco/rules_helm/tree/0.10.0?tab=readme-ov-file#helm_upgrade already has the ability to do all the above, but I must express my stack of k8s components in the form of a helm chart. Helm offers pre-install, post-install, pre-upgrade, post-upgrade, and fancy formatting of templates. But this all invites laziness with its imperative approach where k8s seeks a more declarative approach.

Additional Context:
Flux is a common tool that can take raw yaml files in a git repo and consume changes to push them to a k8s cluster. But having raw yamls, even if flux can work in kustomize, lacks the richness of being able to import libraries and inherit templates. While k8s tries not to be opinionated on how to generate the yaml, bazel enables us to generate using an ever-growing landscape of configuration tools. Sadly flux doesn't know how to execute bazel build rules, then find the artifacts and push that intent to k8s.

Bazel has the ability to consistently build a binary, package it into a docker container (without any internet thanks to rules_oci providing base images suiting a variety of programming language dependency needs), compute the sha256, and (thanks to rules_oci) push that image to a repo, finally giving us a way to lock in an RGD not only with the k8s resources and their dependencies, but also the binary itself via locked in (via sha256) docker images. Bazel gives us a Bill of Materials.

• Please vote on this issue by adding a 👍 reaction to the original issue
• If you are interested in working on this feature, please leave a comment

[borg286]

Perhaps a better alternative would be to look at
https://github.com/fasterci/rules_gitops
They are supporting bzlmod and rules_oci
It also has a way to specify dependencies and kustomize overlays. We could theoretically bundle all these dependencies into a single RGD.