You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to be able to authenticate against multiple registries, not just one.
There can be the issue where you run into dockerhub limits (thus desire to authenticate against it to double your pull limit) and then also requiring authentication agains another container registry which is hosting semi-public or private images.
Suggestion 1:
Make the container runner more clever and let it read more registries authentication from the env vars.
Example vars:
Suggestion 2:
Make use of the NewAuthConfigurationsFromDockerCfg func of dockertest to read from .docker/config or .dockercfg files automatically.
This would be cleaner in my opinion on the application/library side, but might require manual creating the docker config on the ci job.
Also take this into account: ory/dockertest#487
I would prefer to implement the latter as the library shouldn't bother about complexity of the ci and should rather "feel native".
The text was updated successfully, but these errors were encountered:
I would like to be able to authenticate against multiple registries, not just one.
There can be the issue where you run into dockerhub limits (thus desire to authenticate against it to double your pull limit) and then also requiring authentication agains another container registry which is hosting semi-public or private images.
Suggestion 1:
Make the container runner more clever and let it read more registries authentication from the env vars.
Example vars:
Suggestion 2:
Make use of the
NewAuthConfigurationsFromDockerCfg
func of dockertest to read from.docker/config
or.dockercfg
files automatically.This would be cleaner in my opinion on the application/library side, but might require manual creating the docker config on the ci job.
Also take this into account: ory/dockertest#487
I would prefer to implement the latter as the library shouldn't bother about complexity of the ci and should rather "feel native".
The text was updated successfully, but these errors were encountered: