extraDirectory doesn't work with symbolic links as either destination or source

[prashantpro]

Description of the issue: I have a maven project structure and have used the default jib location of extraDirectory.

src/main/jib/ Added my desired file i.e. 'server.xml' that needed to be placed under '/config' within the base image. Thus, the structure now looked like this: (As jib requires recreating the structure under 'jib' directory)

src/main/jib/config/server.xml

The destination directory '/config' is actually a symbolic link in the base image. After jib creates the image, on inspecting it can be seen that the symbolic link has now got replaced with an actual directory. Which breaks the build for me.

Expected behavior:

Symbolic link directories are typical in Java EE server images where these links are provided for deployment or configuration file placement. Here the 'config' directory is the case for openliberty server.

Would expect this structure to be preserved if possible. Or provide some means of achieving the goal of putting files under images which use a symbolic link as a destination folder.

Environment: Maven 3.5 Java 8 OS - MacOS

jib-maven-plugin Configuration:

<plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <version>1.0.2</version>
                <configuration>
                    <from>
                        <image>openliberty/open-liberty:javaee8-java8-openj9</image>
                    </from>
                    <to>
                        <image>demo-project:1.0</image>
                    </to>
                    <container>
                        <appRoot>/apps/</appRoot>                        
                    </container>
                </configuration>
            </plugin>

Additional Information: I inspected the image by logging into it with bash (running container). And I can see that the symbolic link 'config' within the server, now got changed to an actual directory.

Let me know if you need more details? This actually should be easily reproducible without requiring any Java or server technology, it's just a matter of how JIB copies the structure on the base image.

[loosebazooka]

Hey @prashantpro. Thanks for bringing this up.

The workaround for this is to just directly reference the target that the link is referencing. I image that would be annoying if you're swapping servers regularly but might be acceptable for a simple case.

We currently have this low priority on our schedule, and given how jib works might consider not solving this. However if we get enough attention we can take another look. So please thumbs up this issue if it is seriously affecting you.

[prashantpro]

Low priority is fine, I don't think this is a deal breaker. And yes, that workaround suggested is what I had ended up doing to move ahead. I brought this up as an issue in case it was something simple to solve that the team could have closed.

The ugliness (opinionated) of the issue is that I need to create multiple directories. Example of what I needed to do to solve this case:

/src/main/jib/opt/ol/wlp/usr/servers/defaultServer/

Here jib will correctly copy the desired configuration file to destination directory. Thanks.

[briandealwis]

I'm going to re-open this as there's a workaround but not a solution. If others encounter this issue, please describe your situation here.

[meier297]

It took me a while to realize, that jib replaces the symbolic link. A hint at the section could be helpful.

[yugui]

I tried to install busybox on top of another base image. But I could not create symbolic links for busybox aliases.

I wonder if we can have similar features to the ones in Bazel rules_docker. rules_docker, which has a similar build mechanism, provides two interesting attributes:

• tars: this attribute allows users to extract tar archives into the image layer. It looks to be feasible in Jib to inject given tar archives as extra layers of the target image.
• symlinks: this attribute specifies symbolic links to be created in the layer.

[chanseokoh]

So there are two sides of the issue:

1. source symlinks (creating symlinks in an image): as suggested in https://github.com/GoogleContainerTools/jib/issues/1576#issuecomment-503810403 and supported in Bazel rules_docker, it sounds like a good idea to support this. Note this is really #2275.
2. destination symlinks (following symlinks in a base image when copying files from <extraDirectories>): this is tough to support. We may need to list file contents of base image layers, statically analyze symlinks, and put files in correct destination directories.

[putsev]

I have the similar case: extraDirectories with symlinked file in them - C++ binaries, which I have to run with my Java application. But JIB just put the copy of the file instead symlink. This increases the size of image significantly.

[NitinSharma1991]

I have to copy Python binaries. I have run the script from my Java application. Can somebody help if that can be done? If I am copying them it's failing with an error. couldn't follow symbolic link