Added docker_config_json parameter

[markround]

This means you can specify a full ~/.docker/config.json file to use for authentication, which is useful to work around Docker Hub's rate-limiting.

You can pass this in (e.g. from a secrets source such as Credhub or k8s secrets), and authenticate against multiple registries.

Also added GODEBUG="x509ignoreCN=0" env var to work around "legacy CN" format SSL certificates warning, introduced with latest version of Go SSL library.

[markround]

This is a work-around for #278 which has recently bitten me due to Docker Hub's rate-limiting. I needed to be able to drop a raw docker config.json in so I can authenticate against multiple registries e.g. log into Docker Hub so I don't get rate-limited when pulling base images, but also authenticate against my target private registry.

Hope this helps someone in any case!

[xtremerui]

Hi, thx for the PR. Have you tried https://github.com/concourse/registry-image-resource? We encourage users to move to registry-image-resource rather than adding new features to this resource type (though this PR falls between new feature and bug fix as the change is introduced from docker itself)

If that works in your case I'd rather hold on this PR since all your credetials will be stored plain text in the config file, refer to https://github.com/concourse/docker-image-resource/issues/243

[markround]

@xtremerui The registry-image-resource doesn't really work for me, as it doesn't deal with building containers using public base images. Which is where I was being badly bitten by Docker Hub's rate-limiting when not authenticating as I'm behind CGNAT and presumably sharing my public IP with 100s/1000s of other users.

I could I guess hook registry-image up to the oci-build resource but that's somewhat in flux at the moment and doesn't really offer anything at the moment over this resource as far as I can see (e.g. it still requires privileged: true, although I think that's planned to change in the future).

I understand the hesitation to merge given the config file being written to disk, but then as far as I understand it, that's still what happens with the "docker login" approach. Although I agree it's not best practice to leave credentials floating around on disk.

I'm fine with whatever you choose to do though :)

The fact that this PR exists and is linked in the associated issue is enough for me, hopefully it'll help someone else with a workaround in the worst-case scenario.