Bazel Monorepo - 如何仅重建和发布更改的 Docker 映像？

Question

客观的

我有一个 monorepo 设置，其中包含越来越多的服务服务。当我部署应用程序时，我运行一个命令，每个服务都将被重建，最终的 Docker 镜像将被发布。但是随着服务数量的增加，重建所有服务所需的时间越来越长，尽管只对其中的几个进行了更改。

为什么我的设置重建了所有 Docker 镜像，尽管只有少数镜像发生了变化？我的目标是仅重建和发布实际更改的图像。

细节

我正在使用 Bazel 构建我的 Docker 映像，因此在我的项目的根目录中有一个BUILD文件，其中包含我要部署时运行的目标。它只是 的集合k8s_objects，其中包含每项服务：

load("@io_bazel_rules_k8s//k8s:objects.bzl", "k8s_objects")
k8s_objects(
    name = "kubernetes_deployment",
    objects = [
        "//services/service1",
        "//services/service2",
        "//services/service3",
        "//services/service4",
        # ...
    ]
)

同样BUILD，每个服务都有一个文件，它首先从所有源文件创建一个 Typescript 库，然后创建 Node.Js 图像，最后将图像传递给 Kubernetes 对象：

load("@npm_bazel_typescript//:index.bzl", "ts_library")
ts_library(
    name = "lib",
    srcs = glob(
        include = ["**/*.ts"],
        exclude = ["**/*.spec.ts"]
    ),
    deps = [
      "//packages/package1",
      "//packages/package2",
      "//packages/package3",
    ],
)

load("@io_bazel_rules_docker//nodejs:image.bzl", "nodejs_image")
nodejs_image(
    name = "image",
    data = [":lib", "//:package.json"],
    entry_point = ":index.ts",
)

load("@k8s_deploy//:defaults.bzl", "k8s_deploy")
k8s_object(
  name = "service",
  template = ":service.yaml",
  kind = "deployment",
  cluster = "my-cluster"
  images = {
    "gcr.io/project/service:latest": ":image"
  },
)

请注意，Typescript 库还依赖于一些包，在重新部署时也应考虑在内！

要部署我运行 bazel run :kubernetes_deployment.apply

---

最初我决定选择 Bazel 的一个原因是因为我认为它只能处理构建变化的服务本身。但显然情况并非如此，或者我的设置在某些方面有问题。

如果您需要对项目进行更详细的了解，可以在此处查看：https : //github.com/flolude/cents-ideas

Answer 1

看起来 Bazel repo 本身做了类似的事情：

https://github.com/bazelbuild/bazel/blob/ef0f8e61b5d3a139016c53bf04361a8e9a09e9ab/scripts/ci/ci.sh

大致步骤是：

• 计算已更改的文件列表
• 使用文件列表并找到它们的依赖项（例如 bazel 查询kind(.*_binary, rdeps(//..., set(file1.txt file2.txt)))将找到依赖于 或 的所有二进制file1.txt目标file2.txt）
• 构建/测试目标列表

您需要根据您的需要调整此脚本（例如，确保它找到 docker 映像目标）

要找出目标的类型，您可以使用bazel query //... --output label_kind

编辑：对任何想要进入这个兔子洞的人的一点警告（特别是如果你绝对不想错过 CI 中的测试）：

你需要考虑：

• 删除的文件/BUILD 文件（谁依赖它们）
  • 请注意，移动的文件==已删除+已添加
  • 此外，您也无法查询不再存在的文件/构建的反向依赖！
• 修改BUILD文件（为了安全起见，请确保BUILD中所有目标的所有反向依赖都已构建）

我认为沿着这条路线走下去有很多复杂性（如果可能的话）。依靠 Bazel 本身来找出发生了什么变化、使用远程缓存并--subcommands计算需要执行哪些副作用可能不太容易出错。