英文:
authenticate docker for gcp artifact registry in bazel test
问题
我有一个 bazel 测试，它执行 docker build 和 docker push 将 Docker 镜像推送到 Google Artifact Registry。它失败了，因为无法创建私有文件：
/home/bill/.config/gcloud/credentials.db。
我可以通过在 bazel 规则中使用 local=True 来关闭 bazel 沙箱，或者避免使用 docker push（即使用本地镜像进行测试）。有更好的解决方法吗？
英文:
I have a bazel test that docker build and docker push to google artifact registry a docker image. It fails, because "cannot create private file:
/home/bill/.config/gcloud/credentials.db".
I can turn off bazel sandboxing by either using local=True in bazel rule or avoid docker push (i.e. test with local image). Is there some better work-around?
答案1
得分: 2
你可以使用Bazel的--sandbox_writable_path标志来明确指定路径。如此文档所述：
对于沙盒操作，使沙盒中的现有目录可写（如果受沙盒实现支持，则会被忽略）。
--sandbox_writable_path会在运行操作时要求沙盒将现有目录设为可写。
似乎--sandbox_writable_path标志适用于整个构建过程，不可能在每个测试规则基础上进行指定。
英文:
You can use Bazel's --sandbox_writable_path flag to explicitly specify the path. As mentioned in this document
>For sandboxed actions, make an existing directory writable in the sandbox (if supported by the sandboxing implementation, ignored otherwise).
>
>--sandbox_writable_path, which asks the sandbox to make an existing directory writable when running actions.
Seems the flag --sandbox_writable_path applies to the entire build process, Not possible to specify on a per test rule basis.
答案2
得分: 0
我建议不要在bazel build或bazel test规则内部执行docker push，因为它会产生副作用（即，镜像可能会出现在远程服务器上）。一般来说，这可能会引发以下问题：
- 其他团队/开发人员可能不知道特定的构建/测试目标具有这些副作用。在这种特定情况下，如果任何内容依赖于标签，将标签推送到标签可能会有问题，因为它可能在不提前警告的情况下更改标记的版本，并且变得更难以推断标记当前指向哪个代码/镜像。
- 具有副作用的测试目标的并发运行（例如，使用
--runs_per_test=10）可能会在外部系统上引发竞争；外部系统上的状态可能是不确定的，或者在发生竞争时，外部系统出现错误可能会导致测试目标出现虚假失败。 - 构建输出/测试结果可能无法缓存（一个尝试重新运行测试以执行副作用的操作，但bazel正在尝试积极地缓存测试结果，例如）。
具有副作用的命令最好放在脚本/二进制文件中，并通过bazel run触发。这确实会使需要执行多个bazel步骤才能完成的端到端流程变得复杂；然而，它保持了不希望具有副作用的bazel调用与可能具有副作用的bazel调用之间的清晰界限，这将更符合用户和工具的期望。
英文:
I recommend not doing a docker push from within a bazel build or bazel test rule, because it has side-effects (namely, an image may become present on a remote server). Generally speaking, this can cause issues:
- other teams/devs may not be aware that a particular build/test target has these side effects. In this specific case, pushing to a particular tag is problematic if anything depends on the tag, because it could change the tagged version without warning, and it becomes harder to reason about what code/image the tag currently points to
- concurrent runs of a test target (e.g. with
--runs_per_test=10) with side effects can cause a race on the external system; the state on the external system may be indeterminate, or the test target may spuriously fail if the external system errors when races occur - build outputs/test results may not be cacheable (one is trying to rerun the test to execute the side effect, but bazel is trying to aggressively cache the test result, for instance)
Commands with side-effects are best put inside a script/binary and triggered via bazel run instead. This does complicate end-to-end-type flows, that may need to execute more than one bazel step to complete; however, it keeps a clear delineation between bazel invocations that are not expected to have side effects vs. those that might, which will line up better with user and tool expectations.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论