jib: Randomly failing maven build with WindowsException
Description of the issue: From time to time I get the following exception failing the build. It seems Windows related with some cache access error. The root exception I get is AccessDeniedException based on some WindowsExceptions. It happens quite often when the build runs through very fast. When I’m on battery with my laptop (slower CPU freq) the error doesn’t occur. Could this also be due to some concurrency in jib during the build?
Caused by: java.nio.file.AccessDeniedException: C:\Users\I506803\examples\personservice\target\jib-cache\tmp\4235202945488612732 -> C:\Users\I506803\examples\personservice\target\jib-cache\layers\b4617547f616e55fb347a9d4cf7db25dc27bf11608a4e6ef749c13df3334538b
at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:83)
at sun.nio.fs.WindowsException.rethrowAsIOException (WindowsException.java:97)
at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:387)
at sun.nio.fs.WindowsFileSystemProvider.move (WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move (Files.java:1395)
at com.google.cloud.tools.jib.cache.DefaultCacheStorageWriter.moveIfDoesNotExist (DefaultCacheStorageWriter.java:74)
at com.google.cloud.tools.jib.cache.DefaultCacheStorageWriter.write (DefaultCacheStorageWriter.java:184)
at com.google.cloud.tools.jib.cache.DefaultCacheStorage.write (DefaultCacheStorage.java:69)
at com.google.cloud.tools.jib.cache.Cache.writeUncompressedLayer (Cache.java:82)
at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:138)
at com.google.cloud.tools.jib.builder.steps.BuildAndCacheApplicationLayerStep.call (BuildAndCacheApplicationLayerStep.java:40)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:125)
at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:57)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:78)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
[ERROR]
[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
Steps to reproduce: Build container on Windows. Still hard to reproduce since the bug occurs randomly.
Environment: jib-maven-plugin 1.0.2, Windows 10
jib-maven-plugin Configuration:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>${jib.version}</version>
<configuration>
<to>
<image>registry.hub.docker.com/${docker.repositoryname}/mongokubernetes:${project.version}</image>
<credHelper>${jib.credentialhelper}</credHelper>
</to>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (9 by maintainers)
I don’t think this is a concurrency issue, if you are not running multiple Jib builds in parallel or building a multi-module project. There was a similar case before (#1438), and the cause was an anti-virus software. Make sure you close any file explorer (from my experience, if you have ever opened a folder in an explorer, then even if you close and navigate away from the folder, I’ve seen cases where you cannot delete the folder until you close the explorer) and any command line windows, and disable anti-virus.
For further testing, you can do
mvn -Djib.serialize=true ...to run a build serially. You can also use-Djib.applicationCache=...to use a different application cache directory thantarget/jib-cache(https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#system-properties).UPDATE: if the problematic directory is not an application cache directory (cache for your single project) but the central base image cache shared across Jib projects on the same machine (like in #3740), you’d try
-Djib.baseImageCache=...instead of-Djib.applicationCache=...for testing. However, remember that this is changing the shared cache, so if you decide to do this for a short-term solution, you’ll want to set this for all Jib runs across projects to benefit the cache.@chanseokoh ,
AccessDeniedException. I upgraded but it was the same issue still.