jib: gradle jibDockerBuild fails with Could not expand ZIP message on second run

Description of the issue: I started to use jib for war files. My war file has read only files. When I run gradle jibDockerBuild second time it fail with message: Execution failed for task ‘:bundle-svc:jibExplodedWar’.

Could not expand ZIP ‘…/bundle-svc/build/libs/bundle-service.war’.

Expected behavior: It shouldn’t fail and should complete successfully

Steps to reproduce: In existing gradle project that produces a war file, change a file to be read only. Run gradle jibDockerBuild

Environment: Mac Os X, Gradle 4.10.3

jib-gradle-plugin Configuration:


jib {
  from.image = 'localhost:5000/repo/bundle-service:latest'
  allowInsecureRegistries = true
  to.image = 'repo/bundle-service-jib'
  // For demonstration only: this directory in the base image contains a Tomcat default
  // app (welcome page), so you may first want to delete this directory in the base image.
  container.appRoot = '/opt/tomcat/webapps'
}

Log output:

Additional Information: Changing original file permission can’t be a workaround to me since I use Perforce as a VCS which sets readonly flag for all files that weren’t checked out.Those files are packed to war as is with the standard gradle war task.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 17 (14 by maintainers)

Commits related to this issue

Most upvoted comments

@infa-rbliznet we just released Jib 1.8.0, and I believe it fixes this issue.

@rajovictor thanks for your contribution to fix this!

I am using only ExplodedWarTask#setWarFile along with TempDirectoryProvider as you did in #2069 and it works. I will modify the unit and integration tests and create a PR.

Yes, we can unzip this into a temp directory. Judging from the reported issue, it looks like we are always unzipping a WAR. I don’t see any problem with a temp directory; it will just be a different directory than jib-exploded-war. I think using a temp directory is actually better, since users can remove files from a WAR during development, and since we are not cleaning the exploded directory, it is possible that unwanted files get containerized currently.