`appRoot` and sub dirs / files owned by root

Description of the issue:

The resulting image has all files in appRoot owned by root, even when the user parameter is set in the configuration. While my own container appears to work, it would be better to not have these files owned by root. It could cause unknown results on restrictive container platforms (like OpenShift).

Expected behavior:

If the user option is set, then all the files created by the build should be owned by that user id/name for consistency.

Steps to reproduce:

<plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>0.10.0</version>
        <configuration>
          <from>
            <image>mlbiam/openunison-jib-builder:latest</image>
          </from>
          <container>
            <user>431</user>
            <appRoot>/usr/local/openunison/work/webapp</appRoot>
            <entrypoint>/usr/local/openunison/bin/run_openunison.sh</entrypoint>
          </container>
          <to>
            <image>mlbiam/testadlogin</image>
          </to>
        </configuration>
      </plugin>

run a build and look at /usr/local/openunison/work/webapp all the files are owned by root:

openunison@openunison-7b7b6df97b-bks92:/$ cd /usr/local/openunison/work/webapp
openunison@openunison-7b7b6df97b-bks92:~/work/webapp$ ls -lh
total 24K
drwxr-xr-x  2 root root 4.0K Jan  1  1970 META-INF
drwxr-xr-x  1 root root 4.0K Jan  1  1970 WEB-INF
drwxr-xr-x  4 root root 4.0K Jan  1  1970 auth
-rw-r--r--  1 root root 1.2K Jan  1  1970 favicon.ico
drwxr-xr-x 10 root root 4.0K Jan  1  1970 k8stoken
drwxr-xr-x 10 root root 4.0K Jan  1  1970 scale
openunison@openunison-7b7b6df97b-bks92:~/work/webapp$ id
uid=431(openunison) gid=433(openunison) groups=433(openunison)

Environment:

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"

jib-maven-plugin Configuration:

<plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>0.10.0</version>
        <configuration>
          <from>
            <image>mlbiam/openunison-jib-builder:latest</image>
          </from>
          <container>
            <user>431</user>
            <appRoot>/usr/local/openunison/work/webapp</appRoot>
            <entrypoint>/usr/local/openunison/bin/run_openunison.sh</entrypoint>
          </container>
          <to>
            <image>mlbiam/testadlogin</image>
          </to>
        </configuration>
      </plugin>

Additional Information:

I’d be happy to create a PR for this

[chanseokoh]

@mlbiam @eoftedal @mserdur @markdbuck @tdittmann @slowr @ch-wc @carljmosca @hansenc The Jib Extension Framework is now available with the latest Jib versions. You can easily extend and tailor the Jib plugins behavior to your liking.

Since there’s a very compelling reason to allow the container to be mutable at runtime (e.g., running Skaffold to update class files on Kubernetes during development), we’ve decided to support this use case through an extension:

• Maven Ownership Extension
• Gradle Ownership Extension

For general information about using and writing extensions, take a look at the Jib Extensions repo.

Use of these extensions is still discouraged unless absolutely needed.

[markdbuck]

@chanseokoh is correct that my use case for skaffold/jib integration is for the quick development cycle and not for production. However, it is still an important one for my organization. I have made it work well with skaffold/docker build where I can control the file permissions in the image. I make the class files group writeable and then using my IDE, I can edit a Java source file, press save and the rest is automatic. The IDE compiles the Java, skaffold detects the modified class file and syncs it into the container, and then Tomcat reloads it. No waiting for the image to build and push to the registry. I wish I could have made it work with jib but understand your perspective.