executable permission is never set

Description of the issue:

If you add a executable file to src/main/resources or src/main/jib the resulting docker image will include the files only with mode 0644.

Expected behavior:

The files should have a mode of 0744

Additional Information:

https://github.com/GoogleContainerTools/jib/blob/8fbdb2e1b1018565388c3036540125b852ddc142/jib-core/src/main/java/com/google/cloud/tools/jib/image/ReproducibleLayerBuilder.java#L68

Creates a new TarArchiveEntry for each File. The TarArchiveEntry will always use TarArchiveEntry. DEFAULT_FILE_MODE for all files (0100644).

A possible change could be something like this:

if(java.nio.file.Files.isExecutable(sourceFile))
  tarArchiveEntry.setMode(tarArchiveEntry.getMode() | 0100);

[coollog]

@danielpetisme Thanks for the suggestion! That syntax looks nice, though we are trying to limit new configuration objects to reduce the keep at a minimum the complexity of Jib’s configuration.

Based on your proposal, we came up with the following that changes the existing extraDirectory configuration to include permissions:

<extraDirectories>
  <paths>(defaults to src/main/jib)</paths>
  <permissions>
    <permission>
      <file>/file/in/container</file>
      <mode>755</mode>
    </permission>
  </permissions>
</extraDirectories>

Thoughts? @GoogleContainerTools/java-tools

[danielpetisme]

I 👍 this issue. I’ve integrated jib into jhipster generator and I must use a custom entrypoint.sh. This file is stored under src/main/jib and set as executable but once copied on the container image, the file is not executable anymore. This problem forces me to run a dircty chmod +x before running the script 😢 It’s not a blocking point but its a pitfall we could avoid.

I don’t how I could help?