Consider the possibility of using <permissions> without <paths>, if the default path is used

[Gumichan01]

Environment:

• Jib version: 1.8.0
• Build tool: Maven 3.6.2
• OS: Windows

Description of the issue:

I wrote this piece of XML content in my pom.xml:

<extraDirectories>
    <permissions>
        <permission>
            <file>/app/docker-entry-point.sh</file>
            <mode>755</mode>
       </permission>
    </permissions>
</extraDirectories>

I did not used the <paths> parameter because as explained here, by default, Jib uses src/main/jib/ as the default path if the parameter is not set.

NB: /app/docker-entry-point.sh exists in src/main/jib/. What this files contains doesn't matter.

So, assuming that the <paths> is set when I use the <permissions> parameter, I execute mvn jib:dockerBuild. When I explore the docker image (thanks dive), I notice that the entry point still has the default permission ("644").

Screenshot

However, it works properly when I use the <paths>:

<extraDirectories>
    <paths><path>src/main/jib</path></paths>
    <permissions>
        <permission>
            <file>/app/docker-entry-point.sh</file>
            <mode>755</mode>
       </permission>
    </permissions>
</extraDirectories>

It makes sense to use the paths and the permissions parameters together if the path has not the default value, but I don't understand why I must explicitly use <paths>src/main/jib</paths> in odrer to set file permissions properly. It seems redundant.

Expected behavior:

I expect the file to have this permission: "755" ( -rwx-r-xr-x)

Steps to reproduce:

1. Create a simple Maven project and create a docker-entry-point.sh in src/main/jib.
2. Integrate this XML content in the POM file.

<plugin>
    <executions>
        <execution>
            <phase>package</phase>
                <goals>
                    <goal>build</goal>
                </goals>
        </execution>
    </executions>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>1.8.0</version>
    <configuration>
        <extraDirectories>
            <permissions>
                <permission>
                    <file>/app/docker-entry-point.sh</file>
                    <mode>755</mode>
                </permission>
            </permissions>
        </extraDirectories>
        <to>
            <image>test-image</image>
            <tags>
                <tag>${project.version}</tag>
            </tags>
        </to>
        <container>
            <entrypoint>/app/docker-entry-point.sh</entrypoint>
        </container>
    </configuration>
</plugin>

3. Run mvn jib:dockerBuild
4. Explore the docker image generated.
   • If you have dive installed on your machine, run dive <id_of_the_docker_image>

[chanseokoh]

Thanks for the report. We weren't aware of this, but it turns out this is fixed in #2108 we merged after releasing 1.8.0. The fix will be included in the next release.

[TadCordle]

@Gumichan01 2.0.0 has been released and should fix this issue.