authenticate docker for gcp artifact registry in bazel test

Question

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?

Answer 1

You can use Bazel's --sandbox_writable_path flag to explicitly specify the path. As mentioned in this Bazel's doc

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.

Answer 2

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.