1.7.0 noticeably slower than 1.6

Environment:

• Jib version: 1.7.0
• Build tool: Maven 3.6.1 (embedded in Eclipse 4.13, running on AdoptOpenJDK 13+33)
• OS: Windows 10

Description of the issue: I have noticed a roughly 30% increase in the length of time building an image takes with 1.7.0 vs 1.6.x versions.

The delay seems to occur between these two log lines:

[INFO] Retrieving registry credentials for registry-1.docker.io… and [INFO] Using base image with digest: sha256:b2cb057d533ccf5b646e112184b00bb64c05b12535acf2bb5d30b7c08bed6c7c

Expected behavior: No degradation in build time

Steps to reproduce:

1. Build image with 1.6.1
2. Change JIB plugin conf to use 1.7.0
3. Build image and compare times

jib-maven-plugin Configuration:

			<plugin>
				<groupId>com.google.cloud.tools</groupId>
				<artifactId>jib-maven-plugin</artifactId>
				<version>1.7.0</version>
				<configuration>
					<from>
						<image>adoptopenjdk/openjdk13:debian-slim</image>
						<auth>
							<username>[removed]</username>
							<password>[removed]</password>
						</auth>
					</from>
					<to>
						<image>${docker.repository}/${project.artifactId}</image>
						<auth>
							<username>[removed]</username>
							<password>[removed]</password>
						</auth>
					</to>
					<extraDirectories>
						<paths>
							<path>../ecv-devops/monitoring/jib/</path>
						</paths>
					</extraDirectories>
					<allowInsecureRegistries>true</allowInsecureRegistries>
					<container>
						<jvmFlags>
							<jvmFlag>-javaagent:/appdynamics/AppServerAgent/javaagent.jar</jvmFlag>
							<jvmFlag>-XX:+HeapDumpOnOutOfMemoryError</jvmFlag>
							<jvmFlag>-Djava.security.egd=file:/dev/./urandom</jvmFlag>
						</jvmFlags>
						<creationTime>USE_CURRENT_TIMESTAMP</creationTime>
					</container>
				</configuration>
			</plugin>

Log output: [INFO] — jib-maven-plugin:1.7.0:build (default-cli) @ ecv-webapp — [WARNING] Authentication over HTTP is enabled. It is strongly recommended that you do not enable this on a public network! [WARNING] Setting image creation time to current time; your image may not be reproducible. [INFO] [INFO] Containerizing application to [removed]/ecv-webapp… [WARNING] Base image ‘adoptopenjdk/openjdk13:debian-slim’ does not use a specific image digest - build may not be reproducible [INFO] Retrieving registry credentials for [removed]… [INFO] Getting manifest for base image adoptopenjdk/openjdk13:debian-slim… [INFO] Building dependencies layer… [INFO] Building resources layer… [INFO] Building classes layer… [INFO] Building extra files layer… [INFO] The base image requires auth. Trying again for adoptopenjdk/openjdk13:debian-slim… [INFO] Retrieving registry credentials for registry-1.docker.io… [INFO] Using base image with digest: sha256:b2cb057d533ccf5b646e112184b00bb64c05b12535acf2bb5d30b7c08bed6c7c [INFO] [INFO] Container entrypoint set to [java, -javaagent:/appdynamics/AppServerAgent/javaagent.jar, -XX:+HeapDumpOnOutOfMemoryError, -Djava.security.egd=file:/dev/./urandom, -cp, /app/resources:/app/classes:/app/libs/*, [removed]] [INFO] [INFO] Built and pushed image as [removed]

Additional Information:

Looking for advice initially on what debugging can be turned on to try and identify which part of the process is slower. I can see in 1.7.0 there were a number of changes in how images were produced so suspect something in my environment is creating a slow down in relation to this.

The repository I am pushing to is remote (AWS EC2 instance).

[raizoor]

I have compared the times between these versions, using maven 3.6 and openjdk11, using my internal registry (harbor - https) and can’t see these slowness problem too. I’m using mvn compile jib:build.

[chanseokoh]

Yeah, I also tried 1.6.0 vs 1.7.0 with GCR (gcr.io) that gives consistent and reliable speed but haven’t noticed difference. I get very consistent results for both. Anyways, you can pass -X to Maven to see Jib’s rough timing logs on various operations.

Unrelated, since you said the registry is a remote one on AWS EC2, I discourage using <allowInsecureRegistries> if the network traffic goes through the Internet. Especially if you have to use -Djib.sendCredentialsOverHttp, that means you are talking to the registry over plain HTTP, and it is extremely easy for anyone in the wild to see your username and password.