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:
|
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 list output: Java example 1
-
Using the provided repository value when no ServerURL is 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.
Currently, the implementation of
CredentialProvider.getAuthConfiguses the resolved credential provider program (if one is configured for given repository) to first execute thelistsubcommand to get the list of supported registries and only if specified registry is on that list, executes thegetsubcommand 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
I propose removing the logic of checking if the specified registry is included in the output of the
listsubcommand, as I believe it is a redundant check, that in case ofgcloudprovider can actually cause issues.Why is it unnecessary?
If the resolved credential provider does not support the specified repository, the
docker-credential-<provider> getcommand will fail either way. There is no additional benefit in checking the output of thedocker-credential-<provider> listcommand and returning early.Additional use-case for using the
listsubcommand, might be to provide a value for theregistryAddressfield if theresponse.ServerURLvalue is not provided, but from my tests withgcloudprovider (it doesn't return theServerURL), 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 1Using the provided repository value when no
ServerURLis provided: Java example 2What problems does it cause?
In the project i work for, we use
gcloudprovider to authenticate against registries under two separate domains:gcr.ioandpkg.dev.Despite having the registries from both domains in my docker config pointing to the
gcloudcred helper, the commanddocker-credential-gcloud listdoes not list any of thepkg.devregistries.And while the
pkg.devregistries are not included in thelistoutput, when I requestdocker-credential-gcloud getfor that registry, it returns the auth config response correctly.This means that just skipping the
listcheck is enough to make bothgcr.ioandpkg.devregistries 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
gloudprovider against.