-
-
Notifications
You must be signed in to change notification settings - Fork 250
Description
Currently, the implementation of CredentialProvider.getAuthConfig uses the resolved credential provider program (if one is configured for given repository) to first execute the list subcommand to get the list of supported registries and only if specified registry is on that list, executes the get subcommand to actually get the credentials for it.
Related code section:
testcontainers-node/packages/testcontainers/src/container-runtime/auth/credential-provider.ts
Lines 26 to 32 in 0e85014
| const credentials = await this.listCredentials(programName); | |
| const credentialForRegistry = Object.keys(credentials).find((aRegistry) => registryMatches(aRegistry, registry)); | |
| if (!credentialForRegistry) { | |
| log.debug(`No credential found for registry "${registry}"`); | |
| return undefined; | |
| } |
I propose removing the logic of checking if the specified registry is included in the output of the list subcommand, as I believe it is a redundant check, that in case of gcloud provider can actually cause issues.
Why is it unnecessary?
If the resolved credential provider does not support the specified repository, the docker-credential-<provider> get command will fail either way. There is no additional benefit in checking the output of the docker-credential-<provider> list command and returning early.
Additional use-case for using the list subcommand, might be to provide a value for the registryAddress field if the response.ServerURL value is not provided, but from my tests with gcloud provider (it doesn't return the ServerURL), just using the provided registry value works fine.
Looking at other Testcontainers implementations, like java, this is exactly how it is done:
-
Using the credential program directly, without checking the
listoutput: Java example 1 -
Using the provided repository value when no
ServerURLis provided: Java example 2
What problems does it cause?
In the project i work for, we use gcloud provider to authenticate against registries under two separate domains: gcr.io and pkg.dev.
Despite having the registries from both domains in my docker config pointing to the gcloud cred helper, the command docker-credential-gcloud list does not list any of the pkg.dev registries.
And while the pkg.dev registries are not included in the list output, when I request docker-credential-gcloud get for that registry, it returns the auth config response correctly.
This means that just skipping the list check is enough to make both gcr.io and pkg.dev registries work.
As for the change itself, i'm fine with preparing the PR myself, as i already got a working version in my forked branch which I tested the gloud provider against.