Rules_docker: Can't auth to Azure CR

Created on 9 Oct 2019  ยท  54Comments  ยท  Source: bazelbuild/rules_docker

Azure docker config helper is installed. Verified that it works by doing a

docker logout
docker login
docker push

which authed and pushed with no issues.

As for Bazel,

$ bazel --version
bazel 0.29.1

Relevant WORKSPACE:

# Download the rules_docker repository at release v0.11.0
http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "480daa8737bf4370c1a05bfced903827e75046fea3123bd8c81389923d968f55",
    strip_prefix = "rules_docker-0.11.0",
    urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.11.0/rules_docker-v0.11.0.tar.gz"],
)

load(
    "@io_bazel_rules_docker//toolchains/docker:toolchain.bzl",
    docker_toolchain_configure = "toolchain_configure",
)

docker_toolchain_configure(
    name = "docker_config",
    # OPTIONAL: Path to a directory which has a custom docker client config.json.
    # See https://docs.docker.com/engine/reference/commandline/cli/#configuration-files
    # for more details.
    client_config = "/home/[username omitted]/.docker/config.json",
)
# End of OPTIONAL segment.

Relevant BUILD:

container_push(
    name = "push_to_azure",
    image = ":main",
    format = "Docker",
    registry = "[repo name omitted].azurecr.io",
    repository = "from-bazel/main",
    tag = "dev",
)

/home/[username omitted]/.docker/config.json:

{
    "auths": {
        "[repo name omitted].azurecr.io": {}
    },
    "HttpHeaders": {
        "User-Agent": "Docker-Client/19.03.2 (linux)"
    },
    "credsStore": "acr-linux"
}

Results:

$ bazel run :push_to_azure
INFO: Analyzed target //sample_main:push_to_azure (1 packages loaded, 4 targets configured).
INFO: Found 1 target...
Target //sample_main:push_to_azure up-to-date:
  bazel-bin/sample_main/push_to_azure.digest
  bazel-bin/sample_main/push_to_azure
INFO: Elapsed time: 0.133s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 2 total actions
INFO: Build completed successfully, 2 total actions
2019/10/08 17:53:58 Error pushing image to [repo name omitted].azurecr.io/from-bazel/main:dev: unable to push image to [repo name omitted].azurecr.io/from-bazel/main:dev: unsupported status code 401

Any help appreciated

Most helpful comment

@smukherj1 That's all it takes. I have no complaints at all.

All 54 comments

Had same issue with gitlab registry, fixed because i had an issue in the registry URL

i had a double / in the url

registry = "registry.gitlab.com,
repository = "my-project/subname/service_name",

Hi @jasonh-logic2020 ,
-removed suggestion that was not accurate-
Is the "unsupported status code 401" the full error message you are getting or does it have "body: Not Authorized" message.
I'm not sure why you would be getting this message, but I also dont have a good way to repro this. Is this only occurring with the azure repo (i.e., do you push to other private repos in this or other builds?)

Thanks for the reply @nlopezgi. Yes, that's the full error message. Bazel cannot auth to Azure CR and docker can, using the same config.json.

Unfortunately, I have to use Azure for this project.

I'm looking into this, I'll try to land a fix upstream today.

thanks @jonjohnsonjr , do let us know to update our pin as soon as there's something ready!

@jasonh-logic2020 mind helping me debug something?

What's the output of this?

echo "[repo name omitted].azurecr.io" | docker-credential-acr-linux get

Please obfuscate any fields with personally identifiable information, but I'm wondering:

  1. Is Username == <token> or something else?
  2. Is Secret set?

@jonjohnsonjr I sure can! Here you go:

$ echo [repo name omitted].azurecr.io | docker-credential-acr-linux  get
{"ServerURL":"","Username":"[correct username omitted]","Secret":"[correct secret omitted]"}

So the credential helper is returning the actual correct credentials.

Thanks and let me know if I can do anything else.

That's surprising!

Thanks and let me know if I can do anything else.

I really appreciate your patience :)

If you curl -v https://[repo name omitted].azurecr.io/v2/, what's in the WWW-Authenticate header?

You could also try to export GODEBUG=http2debug=1 to get some trace data. I'd be interested in which requests are being sent and what's actually returning a 401, and if there's any headers that indicate we should do something else.

We're trying to use the basic flow, which is essentially:

BASIC_AUTH=$(echo [repo name omitted].azurecr.io | docker-credential-acr-linux  get | jq '.Username + ":" + .Secret' -r | base64 -w0)
curl  <whatever was in the www-authenticate header> -H "Authorization: Basic $BASIC_AUTH"

And I suspect azure really wants us to use oauth. Have you configured docker to use the oauth flow?

I have not specifically configured docker at all. I'm using it pretty much as the Fedora package manager installs it.

Part One:
curl -v https://[repo name omitted].azurecr.io/v2/ and filtering the response for the Www-Authenticate header:

Www-Authenticate: Bearer realm="https://[repo name omitted].azurecr.io/oauth2/token",service="[repo name omitted].azurecr.io"

Part Two:

$ export GODEBUG=http2debug=1
$ bazel run :push_to_azure
INFO: Analyzed target //sample_main:push_to_azure (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //sample_main:push_to_azure up-to-date:
  bazel-bin/sample_main/push_to_azure.digest
  bazel-bin/sample_main/push_to_azure
INFO: Elapsed time: 0.072s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
2019/10/09 12:11:50 http2: Transport failed to get client conn for [repo name omitted].azurecr.io:443: http2: no cached connection was available
2019/10/09 12:11:51 http2: Transport failed to get client conn for [repo name omitted].azurecr.io:443: http2: no cached connection was available
2019/10/09 12:11:51 Error pushing image to [repo name omitted].azurecr.io/from-bazel/main:dev: unable to push image to [repo name omitted].azurecr.io/from-bazel/main:dev: unsupported status code 401

Given that extra logging, I thought I should include:

$ telnet [repo name omitted].azurecr.io 443
Trying 13.66.140.75...
Connected to [repo name omitted].azurecr.io.
Escape character is '^]'.

So apparently yes it's using OAuth. Hopefully that helps?

This is really helpful: realm="https://[repo name omitted].azurecr.io/oauth2/token"

I've got an idea for how to fix this, opened https://github.com/google/go-containerregistry/issues/565

If have the go toolchain installed, would you mind testing this PR to see if it fixes your auth problem?

There's a little CLI associated with that package called crane. If you pull down my branch and go install ./cmd/crane, you can test the changes with something like:

crane ls [repo name omitted].azurecr.io/my/repo

Which will try to list tags in your repository (hopefully successfully).

Sadly, I don't have the full toolchain installed. I can try to get to it but i can't make any promises about whether I have time today.

Sadly, I don't have the full toolchain installed.

No worries - if you're comfortable running random binaries from strangers on the internet, I've uploaded it here.

@jonjohnsonjr I felt bad doing it but in the interests of speed I can confirm that the doctored crane connects and returns the correct list of tags.

@jonjohnsonjr thanks a lot for the super quick turnaround on this! I'll update pins tomorrow and ping here for @jasonh-logic2020 to again.

I felt bad doing it but in the interests of speed I can confirm that the doctored crane connects and returns the correct list of tags.

๐ŸŽ‰ ๐ŸŽ‰ ๐ŸŽ‰

Thanks so much for your help ๐Ÿ˜„

I don't see any 401 or localhost in the logs, it looks more like a github timeout?

Failed to connect to github.com port 443: Connection timed out

ugh, I restarted it to see if it was a flake, and it looks like the re-execution flaked out due to github timeout. Kicked it off again and it is failing with the 401 (it seems consistently):

INFO: Running command line: bazel-bin/external/io_bazel_rules_docker/tests/container/push_test
INFO: Build completed successfully, 70 total actions
2019/10/10 18:23:00 Error pushing image to localhost:5000/docker/test:test: unable to push image to localhost:5000/docker/test:test: unsupported status code 401'
The command "./testing/e2e.sh" exited with 1.

Failure is for this test: https://github.com/bazelbuild/rules_docker/blob/master/testing/e2e.sh#L308

Let me know if you have problems seeing the issue or repro'ing

thanks again! kicked off tests pinned to your not-yet submitted commit to see if it passes. Will update as soon as you submit and get that PR in if it all looks good

Should be fixed with https://github.com/bazelbuild/rules_docker/pull/1197.
Please ping here if the problem persists. Closing for now.

@nlopezgi still doesn't work for me.

Hi @marcus-sa ,
Are you pinning to rules_docker @ head?
Can you detail a bit more about your setup / error so we can try to repro?

Yeah, I'm using the latest commit.

WORKSPACE

workspace(
    # How this workspace would be referenced with absolute labels from another workspace
    name = "[workspace name omitted]",
    # Map the @npm bazel workspace to the node_modules directory.
    # This lets Bazel use the same node_modules as other local tooling.
    managed_directories = {"@npm": ["node_modules"]},
)

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "ad4be2c6f40f5af70c7edf294955f9d9a0222c8e2756109731b25f79ea2ccea0",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/0.38.3/rules_nodejs-0.38.3.tar.gz"],
)

# Setup the Node.js toolchain
load("@build_bazel_rules_nodejs//:index.bzl", "node_repositories", "yarn_install")

node_repositories(package_json = ["//:package.json"])

yarn_install(
    # Name this npm so that Bazel Label references look like @npm//package
    name = "npm",
    package_json = "//:package.json",
    yarn_lock = "//:yarn.lock",
)

# Install any Bazel rules which were extracted earlier by the yarn_install rule.
load("@npm//:install_bazel_dependencies.bzl", "install_bazel_dependencies")

install_bazel_dependencies()

http_archive(
    name = "io_bazel_rules_webtesting",
    sha256 = "9bb461d5ef08e850025480bab185fd269242d4e533bca75bfb748001ceb343c3",
    urls = [
        "https://github.com/bazelbuild/rules_webtesting/releases/download/0.3.3/rules_webtesting.tar.gz",
    ],
)

load("@io_bazel_rules_webtesting//web:repositories.bzl", "web_test_repositories")

web_test_repositories()

http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "f6a3a863ef0d560604ba23eb24e691997eb63dc92062b3e829f6e4994bb419e4",
    strip_prefix = "rules_docker-e473d1f67c3f6dfa8c13363b1863d217331680ee",
    urls = ["https://github.com/bazelbuild/rules_docker/archive/e473d1f67c3f6dfa8c13363b1863d217331680ee.zip"],
)

# Load the macro that allows you to customize the docker toolchain configuration.
load(
    "@io_bazel_rules_docker//toolchains/docker:toolchain.bzl",
    docker_toolchain_configure = "toolchain_configure",
)

docker_toolchain_configure(
    name = "docker_config",
    # Replace this with an absolute path to a directory which has a custom docker
    # client config.json. Note relative paths are not supported.
    # Docker allows you to specify custom authentication credentials
    # in the client configuration JSON file.
    # See https://docs.docker.com/engine/reference/commandline/cli/#configuration-files
    # for more details.
    client_config = ":docker-acr-config.json",
)

load(
    "@io_bazel_rules_docker//repositories:repositories.bzl",
    container_repositories = "repositories",
)

container_repositories()

load(
    "@io_bazel_rules_docker//nodejs:image.bzl",
    _nodejs_image_repos = "repositories",
)

_nodejs_image_repos()

# Setup TypeScript toolchain
load("@npm_bazel_typescript//:index.bzl", "ts_setup_workspace")

ts_setup_workspace()

BUILD

load("@build_bazel_rules_nodejs//:index.bzl", "nodejs_binary")
load("@io_bazel_rules_docker//nodejs:image.bzl", "nodejs_image")
load("@io_bazel_rules_docker//container:container.bzl", "container_push")
load("@npm_bazel_typescript//:index.bzl", "ts_config", "ts_library")

package(default_visibility = ["//visibility:public"])

filegroup(
    name = "assets",
    srcs = glob(["assets/**/*"]),
)

ts_library(
    name = "api_lib",
    srcs = glob(
        include = ["src/**/*.ts"],
        exclude = ["**/*.spec.ts"],
    ),
    tsconfig = "//apps/api:tsconfig-build.json",
    deps = [
        # ....
    ],
)

nodejs_binary(
    name = "api",
    data = [
        ":api_lib",
        ":assets",
    ],
    entry_point = ":src/main.ts",
)

nodejs_image(
    name = "api_image",
    data = [":api"],
    entry_point = ":src/main.ts",
)

container_push(
    name = "push_api_image",
    format = "Docker",
    image = ":api_image",
    registry = "$(container_registry)",
    repository = "$(image_repository)",
    tag = "$(image_tag)",
)

and then I'm pushing the container like so:

$ bazel run --define image_repository=[repo name omitted] --define container_registry=[repo name omitted].azurecr.io --define image_tag=latest //apps/api:push_api_image

The docker-acr-config.json contains this:

{
  "auths": {
    "[repo name omitted].azurecr.io": {
      "auth": "[token omitted]",
      "identitytoken": "[token omitted]"
    }
  }
}

Somehow $ echo "[repo name omitted].azurecr.io" | docker-credential-acr-linux get can't be used because I'm executing it on a remote execution server.

error getting credentials - err: exit status 1, out: `GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files`

thanks for the additional info.
@jonjohnsonjr, does this look to you as the same issue or something else? Any idea what might be happening here? I dont see anything off in the setup, but cant really repro anything on Azure.

still doesn't work for me.

You're breaking my heart!

The docker-acr-config.json contains this

That's interesting. I've never seen an identitytoken in a config file. If you remove the auth entry, does it work? Or if you remove the identitytoken entry, does it work?

Somehow $ echo "[repo name omitted].azurecr.io" | docker-credential-acr-linux get can't be used because I'm executing it on a remote execution server.

It looks like your config file isn't configured to use a credential helper, so it makes sense to me that this would fail.

@jonjohnsonjr forgot to mention I already tried using the property configuration with docker-credential-acr-linux but that didn't work either, as I got the same error as OP but with a status code of 400.

I just copied the docker config from my home directory into docker-acr-config.json, so that's probably why it contains auth and identitytoken

@jasonh-logic2020 can you confirm that you are now fixed? Just want to make sure your issue is separate from @marcus-sa so I can rule that out.

@jonjohnsonjr When I use the crane binary you linked above, it still works.

Since I opened this issue, I have updated to the latest versions of

  • gazelle v0.19.0
  • rules_python 0.0.1
  • rules_nodejs 0.38.3
  • rules_docker v0.12.0

Given that, I'm not sure if I should be seeing a solution to this issue or not.

When I run it, I get

$ bazel run //sample_main:push__to_azure
INFO: Writing tracer profile to '/home/[username omitted]/.cache/bazel/_bazel_[username omitted]/f2dd2bfb2974a88433ae0424106ea3d1/command.profile.gz'
INFO: Analyzed target //sample_main:push_to_azure (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //sample_main:push_to_azure up-to-date:
  bazel-bin/sample_main/push_to_azure.digest
  bazel-bin/sample_main/push_to_azure
INFO: Elapsed time: 0.125s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
2019/10/16 16:37:55 Error pushing image to [repo name omitted].azurecr.io/from-bazel/main:dev: unable to push image to [repo name omitted].azurecr.io/from-bazel/main:dev: unsupported status code 401

This is slightly different to my original error messages, which contained

2019/10/09 12:11:50 http2: Transport failed to get client conn for [repo name omitted].azurecr.io:443: http2: no cached connection was available

just prior to the 401. I don't know whether that's due to your fix being visible to me, my having updated all the external rules, or my having some other error (this is the first time I'm trying to push this particular image to the repo).

If there's any way I can help, I'd be happy to.

I'm getting this aswell

Error pushing image to [repo name omitted].azurecr.io/from-bazel/main:dev: unable to push image to [repo name omitted].azurecr.io/from-bazel/main:dev: unsupported status code 401

This is slightly different to my original error messages, which contained

I think it is actually the same. That error message is from setting GODEBUG=http2debug=1 (it didn't work).

I'm hoping this will help debug: https://github.com/google/go-containerregistry/pull/582

@jonjohnsonjr Correct, that's a piece of config I missed when I set it all up again to re-run the test

@jasonh-logic2020 assuming you don't have the go toolchain stuff set up, I've reuploaded the crane binary with the debug logs flag included.

If you want to run:

crane ls -v [repo name omitted].azurecr.io/my/repo

That will dump a bunch of sensitive stuff that you probably don't want to share over github without redacting, but it might tell us what's going on.

@jonjohnsonjr a redaction task worthy of the [government agency omitted]

$ ./crane2 ls -v [repo name omitted].azurecr.io/[repo first part]/[repo second part]
2019/10/17 15:10:28 defaultKeychain.Resolve("[repo name omitted].azurecr.io") = {"serveraddress":"[repo name omitted].azurecr.io","identitytoken":"[token contents]"}
2019/10/17 15:10:28 --> GET https://[repo name omitted].azurecr.io/v2/
2019/10/17 15:10:28 GET /v2/ HTTP/1.1
Host: [repo name omitted].azurecr.io
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip

2019/10/17 15:10:28 <-- 401 https://[repo name omitted].azurecr.io/v2/
2019/10/17 15:10:28 HTTP/1.1 401 Unauthorized
Content-Length: 87
Access-Control-Expose-Headers: Docker-Content-Digest
Access-Control-Expose-Headers: WWW-Authenticate
Access-Control-Expose-Headers: Link
Access-Control-Expose-Headers: X-Ms-Correlation-Request-Id
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2019 22:10:28 GMT
Docker-Distribution-Api-Version: registry/2.0
Server: openresty
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains
Www-Authenticate: Bearer realm="https://[repo name omitted].azurecr.io/oauth2/token",service="[repo name omitted].azurecr.io"
X-Content-Type-Options: nosniff
X-Ms-Correlation-Request-Id: 0700c1b4-8a14-443f-aafa-29ce49c022fe

{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}
2019/10/17 15:10:28 --> POST https://[repo name omitted].azurecr.io/oauth2/token
2019/10/17 15:10:28 POST /oauth2/token HTTP/1.1
Host: [repo name omitted].azurecr.io
User-Agent: go-containerregistry
Content-Length: 1114
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip

client_id=go-containerregistry&grant_type=refresh_token&refresh_token=[token contents]&scope=repository%!A(MISSING)[repo first part]%!F(MISSING)[repo second part]%!A(MISSING)pull&service=[repo name omitted].azurecr.io
2019/10/17 15:10:28 <-- 200 https://[repo name omitted].azurecr.io/oauth2/token
2019/10/17 15:10:28 HTTP/1.1 200 OK
Transfer-Encoding: chunked
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2019 22:10:28 GMT
Server: openresty
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Ms-Correlation-Request-Id: 53e587cf-80a8-4a49-9aed-131a33604770

39d
{"access_token":"[token contents]"}
0

2019/10/17 15:10:28 --> GET https://[repo name omitted].azurecr.io/v2/[repo first part]/[repo second part]/tags/list
2019/10/17 15:10:28 GET /v2/[repo first part]/[repo second part]/tags/list HTTP/1.1
Host: [repo name omitted].azurecr.io
User-Agent: go-containerregistry
Authorization: Bearer [token contents]
Accept-Encoding: gzip

2019/10/17 15:10:28 <-- 200 https://[repo name omitted].azurecr.io/v2/[repo first part]/[repo second part]/tags/list
2019/10/17 15:10:28 HTTP/1.1 200 OK
Content-Length: 43
Access-Control-Expose-Headers: Docker-Content-Digest
Access-Control-Expose-Headers: WWW-Authenticate
Access-Control-Expose-Headers: Link
Access-Control-Expose-Headers: X-Ms-Correlation-Request-Id
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2019 22:10:28 GMT
Docker-Distribution-Api-Version: registry/2.0
Server: openresty
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Ms-Correlation-Request-Id: d0024626-2de6-49bd-b43d-cd4e9cfd3ad9

{"name":"[repo first part]/main","tags":[[correct tags omitted]]}
[correct tags omitted]

I hope it helps.

a redaction task worthy of the [government agency omitted]

Thanks ๐Ÿ˜„

client_id=go-containerregistry&grant_type=refresh_token&refresh_token=[token contents]&scope=repository%!A(MISSING)[repo first part]%!F(MISSING)[repo second part]%!A(MISSING)pull&service=[repo name omitted].azurecr.io

This looks off...

When I use the crane binary you linked above, it still works.

Oh wait I thought it didn't work? Did I misread that somewhere?

Maybe it's part of the write path? E.g. if you try to do crane cp -v ubuntu [repo name omitted].azurecr.io/my/repo does that fail?

@smukherj1 is there anything in bazel or rules_docker to indicate you want verbose logs? It would be nice to get logs on the actual thing that's failing...

@jonjohnsonjr Yes, crane cp -v ubuntu [repo name omitted].azurecr.io/my/repo successfully pushed.

Is client_config supposed to be a directory?

On Thu, Oct 17, 2019, 4:12 PM jasonh-logic2020 notifications@github.com
wrote:

@jonjohnsonjr https://github.com/jonjohnsonjr Yes, crane cp -v ubuntu
[repo name omitted].azurecr.io/my/repo successfully pushed.

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_docker/issues/1193?email_source=notifications&email_token=AEIJGZUGOQJQ53TYZOBG5VTQPDWOTA5CNFSM4I6Y3DSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBR2SEI#issuecomment-543402257,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEIJGZQJKRHJ4HMWDJO6VPTQPDWOTANCNFSM4I6Y3DSA
.

The docker toolchain already requires Python... Do we need to install Go separately aswell? I love Bazel, but damn there's so many issues that I would barely say it's stable.
The only thing I hate about Google OSS is that it isn't contributor friendly.
It's developed internally and APIs changes without no warnings.
Thousands of people depends on your OSS.
Not directly pointed at the Bazel team, but yeah Google in a nutshell.
If you guys just provided proper documentation.. don't become Microsoft please.

@marcus-sa
thanks for your comments, we do our best to maintain these rules and make them easy to use. You should not need to install go, rules_go uses a hermetic toolchain that downloads all its deps, but do let me know if you see issues here.

I love Bazel, but damn there's so many issues that I would barely say it's stable.

Hopefully things improve with the 1.0 release.

The docker toolchain already requires Python... Do we need to install Go separately aswell?
...
The only thing I hate about Google OSS is that it isn't contributor friendly.
It's developed internally and APIs changes without no warnings.

This was actually one of the motivating factors for switching from the python containerregistry library to go-containerregistry. The former was developed internally, then synced to GitHub, so it was pretty difficult to contribute for external folks (and for us to accept contributions). The latter was developed in the open from the start :smile:

Given the semantic versioning, should I wait for a minor release to test the merge?

I'm using my config file with the credential helper to test this, I have commented out the docker_toolchain_configure rule so I'm assuming it's looking for config.json in ~/.docker by default

@jasonh-logic2020 Can you please first confirm rules_docker at HEAD works for you?

@smukherj1 I'd be happy to. but just make absolutely sure, how do I specify HEAD (or the latest commit) in my http_archive_rule? I don't have the full dev toolchain installed. I'm a mere user so I want to be sure I'm testing correctly.

My current rule is what appears in the README, i.e.

http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "413bb1ec0895a8d3249a01edf24b82fd06af3c8633c9fb833a0cb1d4b234d46d",
    strip_prefix = "rules_docker-0.12.0",
    urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.12.0/rules_docker-v0.12.0.tar.gz"],
)

@jasonh-logic2020 try

http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "d34c323f4db55a2e78d1d92088f0b114cb58e3b7c2380a809d7df4bdb9d3b607",
    strip_prefix = "rules_docker-9a7038509f9306d0b91eea46803a0d5f0760d39e",
    urls = ["https://github.com/bazelbuild/rules_docker/archive/9a7038509f9306d0b91eea46803a0d5f0760d39e.tar.gz"],
)

@smukherj1 Thanks for that. It would not have been my best guess so I'm glad I asked.

I can confirm that it successfully pushed.

nb.: az login is not enough auth to get this to work. az acr login -n [repo name omitted] is required before echo "[repo name omitted].azurecr.io" | docker-credential-acr-linux get returns a non-blank token, at which point this commit works.

nb.: az login is not enough auth to get this to work. az acr login -n [repo name omitted] is required before ```echo "[repo name omitted].azurecr.io" | docker-credential-acr-linux get returns a non-blank token, at which point this commit works.

Perhaps this is something we should add to the docs? Does docker work if you just az login?

@jonjohnsonjr AFAICT, docker login [repo name omitted].azurecr.io always asks for username / password, meaning that it ignores the credential helper in its own config.json.

It all feels a bit rickety, so it's very pleasing to see your work find a path through the tools which works.

It all feels a bit rickety

100% agree. I honestly can't believe how hard it was to even find the documentation about how this stuff is supposed to work.

so it's very pleasing to see your work find a path through the tools which works.

Happy to help :smile:

For the record, I would include the Azure-specific auth requirements in the docs somehow.

Beyond that, :tada:

Looks closeable to me

Looking at our docs here, I see the Azure section links here which does mention az acr login -n <registry name>.

@jasonh-logic2020 Was there something else that was necessary to get your case working?

@smukherj1 works for me as well! Thanks a lot :smile:

@smukherj1 That's all it takes. I have no complaints at all.

Thanks! Special thanks to @jonjohnsonjr! Closing this.

Was this page helpful?
0 / 5 - 0 ratings