Added Docker Pipeline example to README.md

[parrisvarney]

I spend the better part of a day not realizing that the gcr: prefix needed to be in the pipeline file. During that time I must have read this doc a dozen times.

Hoping this quick addition to the doc will save someone else the frustration.

[dvdgsng]

Very useful, thanks. There is literally no documentation on this anywhere but here (and this https://stackoverflow.com/questions/45800883/jenkins-pipeline-build-with-docker-google-registry-and-google-auth-plugin).

Please merge.

[wyardley]

I created https://issues.jenkins-ci.org/browse/JENKINS-49452 to try and get some attention to this.

[oofnikj]

Got burned by this lack of documentation yesterday.

[kponichtera]

Is this plugin still maintained? Its functionality is crucial for those of us who rely on the GCloud's container registry, which doesn't really allow for simple username/password authentication (unless I missed that point in the documentation somehow). The last version is 5 years old and although there are many Jenkins plugins and components which do not receive updates for long time and work just fine, this one is entirely new level - even the small, non-breaking yet important documentation mentions like that one are stalled for 4 years already. What if compatibility issue with newer Jenkins version appears, or even worse - some security issue? I saw some examples of what Google posted in their repo, but these "best practices" of publishing container image to GCR using Kaniko is not something I'd call that - it looks more like a dirty workaround or a weird attempt of trying to show the functionalities of the mentioned plugins, without really taking reasonability into consideration. Not to mentions that these "best practices" are not necessarily fresh either, dating back to 2019.

Not trying to complain here, just wondering - doesn't this plugin quality for being marked for adoption? Right now there are plugins for adoption in Jenkins repository which receive more love than this one does. Should the original maintainer be contacted first for that or is it prerogative of main Jenkins team?

[wwuck]

@craigdbarber @stephenashank @GoogleCloudPlatform is this plugin still maintained by Google? This plugin is currently broken with Jenkins 2.266+ including the latest Jenkins LTS 2.277.1.

[kponichtera]

For some reason I couldn't make this plugin work for me, even after adding gcr: prefix to the credential name. However, I noticed that during pipeline execution it calls docker login -u _token -p ******* which made me recall one of the authentication options in GCloud docs: https://cloud.google.com/container-registry/docs/advanced-authentication#json-key. Translating it to Jenkins use case, it means adding the normal Jenkins username/password credentials with _json_key as the username and the downloaded service account key file content as the password. Then just use it as normal credentials in the pipeline :

docker.withRegistry('https://eu.gcr.io', 'usernamePasswordCredentials') {
  // doing my docker stuff
}

Jenkins will then issue docker login -u _json_key -p '{"type": "service_account", ...}' and authenticate with the GCR. No extra plugins required.

Hope this helps somebody. 🙂

[wwuck]

Thanks @Konpon96 . There is also a similar option to use the json key authentication with Artifact Registry.

https://cloud.google.com/artifact-registry/docs/docker/authentication

It's probably preferable to use _json_key_base64 with a base64-encoded json key and no line wrapping, so you don't need to worry about escaping potential quote characters.

[kponichtera]

The possibility to use base64 with Artifact Registry for encoding the key is actually one of its many benefits over GCR, but I'm yet to migrate to it in my projects. I actually gave it a try and used _json_key_base64 with GCR, but wasn't surprised to get authentication error. 😛 Still, I'm glad that Google decided to keep the ways to authenticate through simple docker login command, without necessarily diving into credential helpers - especially that in my use case they do not offer any extra security benefits and would only complicate the solution.