Feature request: Support configuration or new task that doesn't package a Java app, just specified paths.

Jib and the associated Gradle plugin look to solve a number of problems i’ve come across, and whilst the jib-cli is a great escape hatch to supporting any kind of app/packaging needs the gradle plugin specifically is a great help ergonomically, it avoids having to create jib files and makes it easy to programmatically change jib config per module/project. So I want to use jib and jib gradle plugin, but not all of my containers are Java and even those that are Java I don’t really want to package the app the way Jib wants to out of the box (exploded or packaged modes).

A good way to solve both of these issues would be to tweak the jib gradle plugin to not always assume that a Java app is being packaged, make it an optional addition (defaulted to on for backwards compat) with the disabled state just packaging all the files specified in the extraDirectories section. This way I can use Jib and the gradle plugin, avoid jib files and keep simple per module config AND use the same system for both Java apps and nginx and stubs… etc all of the variety of apps. A slightly different more gradle-aware approach would be to support Gradle Distributions/Applications, whereby Jib aims to package a Gradle application (essentially just a zip/tar constructed by Gradle - https://docs.gradle.org/current/userguide/application_plugin.html) and what is in that application is controlled by Gradle thus breaking the Java app assumption/dependency.

My current workaround is to apply `java-library’ plugin to all my gradle projects so Jib does all the packaging of essentially nothing, just to avoid it failing because the ‘jar’ task doesn’t exist! Quite the silly workaround =)

[nhoughto]

yep makes sense, ok so coordinating concurrent jib builds to share layers will need to be done outside of jib/in gradle itself. My scenario is building 20~ gradle application distributions, they are all java services that share most 3rd party dependencies, this should be easy to split out into its own layer that could be shared. Seems like i’ve got all I need to make that happen, thanks.

[chanseokoh]

Jib caches base image layers and application layers.

The base image layer cache is shared by all Jib tools (Maven and Gradle plugins and Jib CLI). So, as long as base image layers are cached once, they will be reused by any number of concurrent threads or processes running Jib tools.

OTOH, the application layer cache is by default local to each project (build/jib-cache for Gradle and target/jib-cache for Maven). Usually there’s no value to share application layers between projects, since each project is unique and it’s rare that two or more projects build the exact same layers. However, if you have multiple projects that at least have some layers that are built identically, I think it’s not a bad idea to share them by setting their application cache directory to a global location. Check out the jib.applicationCache system property.

Lastly, I think you already know this, but just in case: in order for two layers (which are simply .tar files) to be identical, they should be equal byte-to-byte, resulting in the same digest checksum. Even having a different timestamp for a file makes it different. Good news is that, Jib wipes out highly volatile and system-dependent information like file timestamps, permissions, etc., so it results in strong reproducibility and cacheability, saving storage, network bandwidth, and time.