Jib uses inferred credential provider before .docker/config.json

Description of the issue: I am not able to publish images to the GCR (Google Container Registry), I am running the Jenkins command (mvn -T C4 clean install -DskipTests process-classes -Dbuild.number=$BUILD_NUMBER jib:build), when I squeeze the command through the terminal of linux where it is installed I was able to upload the image, but within jenkins I can not.

Expected behavior: Upload image to gcr.io

Steps to reproduce: Create job in Jenkins and configure to run the command: mvn -T C4 clean install -DskipTests process-classes -Dbuild.number = $ BUILD_NUMBER jib: build

Environment:

Linux Debian 4.9.144-3.1 (2019-02-19) x86_64 Jenkins 2.164.2

• plugin: Google Container Registry Auth Plugin
• credentials GCP Storage Admin JDK 11

jib-maven-plugin Configuration:

			<plugin>
				<groupId>com.google.cloud.tools</groupId>
				<artifactId>jib-maven-plugin</artifactId>
				<version>1.1.2</version>
				<configuration>
					<from>
						<image>openjdk:11-jdk-slim</image>
					</from>
					<to>
						<image>${docker.image.prefix}/eureka</image>
						<tags>
							<tag>${build.number}</tag>
							<tag>latest</tag>
						</tags>
						<credHelper>gcr</credHelper>
					</to>
					<container>
						<jvmFlags>
							<jvmFlag>-Dspring.profiles.active=producao</jvmFlag>
						</jvmFlags>
						<labels>
							<service-name>eureka</service-name>
						</labels>
						<mainClass>br.com.agendeapp.eureka.EurekaServiceApplication</mainClass>
					</container>
				</configuration>
			</plugin>

Log output: [INFO] — jib-maven-plugin:1.1.2:build (default-cli) @ eureka — [INFO] [INFO] Containerizing application to gcr.io/agende-app-222611/eureka, gcr.io/agende-app-222611/eureka:27, gcr.io/agende-app-222611/eureka… [INFO] Retrieving registry credentials for gcr.io… [INFO] Getting base image openjdk:11-jdk-slim… [INFO] Building dependencies layer… [INFO] Building resources layer… [INFO] Building classes layer… [INFO] The base image requires auth. Trying again for openjdk:11-jdk-slim… [INFO] Retrieving registry credentials for registry-1.docker.io… [INFO] [INFO] Container entrypoint set to [java, -Dspring.profiles.active=producao, -cp, /app/resources:/app/classes:/app/libs/*, br.com.agendeapp.eureka.EurekaServiceApplication] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 18.320 s (Wall Clock) [INFO] Finished at: 2019-05-03T17:42:14+00:00 [INFO] Final Memory: 68M/162M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.1.2:build (default-cli) on project eureka: Build image failed, perhaps you should make sure you have permissions for gcr.io/agende-app-222611/eureka: Unauthorized for gcr.io/agende-app-222611/eureka: 403 Forbidden [ERROR] {“errors”:[{“code”:“DENIED”,“message”:“Access denied.”}]} [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException Build step ‘Invoke top-level Maven targets’ marked build as failure Finished: FAILURE

Additional Information: The terminal is installed gcloud sdk, and when trying to run maven the upload occurs

[chanseokoh]

@rafaeldalbosco v1.3.0 is released, and it will give priority to the credentials explicitly configured in .docker/config.json before attempting a well-known credential helper on PATH.

[chanseokoh]

Reversing the order makes sense. Maybe the original intention was that if the registry is gcr.io and there exists a runnable docker-credential-gcr binary, the user should really configure docker-credential-gcr correctly as a priority. However, with the current order, the only way to circumvent the issue is to remove the cred helper (either explicitly or just from $PATH). OTOH, in the reverse case, the user can explicitly configure <credHelper> to override docker.json.