Adding symbolic link support.

[seanleblanc]

Related to: #2275

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[chanseokoh]

Thank you for taking a stab at this, and sorry for the late follow-up. I've mulled over this for a while. Although this is a possible implementation for the support, I actually envisioned a different approach in the past: to have a dedicated configuration in the same way that the Bazel docker_rules takes. Rationale:

• This is a breaking change, and there may be people relying on the current behavior. (However, I'm not saying we cannot make a breaking change.)
• The approach in this PR is universal and absolute, and there's no way to opt out of this behavior. Some people may not want to create symlinks but copy their referenced files.
• It affects source files and directories for all layers, while I think it's safer to restrict it to "extraDirectories."
• On Windows, it can be cumbersome to create symlinks (hence cumbersome to create an image that has symlinks). Even on Linux, I think creating symlinks through configuration and explicit jib-core API is more convenient and robust.
• Bazel docker_rules might have additional reasons to take such an approach that I haven't thought about.
• Configuration and explicit API eliminate ambiguity: otherwise, people may need to try and test symlinks themselves to verify if Jib handles them in the way they want.
• It can be a bit nuanced what to do depending on whether a symlink refers to relative path or absolute path?

So, a configuration like the following at the top level is what have been thinking about:

<links>
  <link>
    <path>/path/to/link</path>
    <target>/path/to/target</target>
    <!-- and potentially type: soft or hard, but perhaps only soft? -->
  </link>
</links>

Unfortunately, I anticipate implementing this will require much more efforts, perhaps extending the public API of jib-core.

[chanseokoh]

Just in case, this idea is not something I capriciously came up with just now: #1576 (comment)

[StefanGoldmann]

Hello chanseokoh,

granted

• the approach as proposed is breaking compatibility
• an explicit API would be nice but imposes a lot more work

As a remedy, wouldn't it be easily possible to keep backwards compatibilty utilizing a flag in the layer builder, say 'retainSymlinks'?
Defaulting this to 'false' would leave everything as is, and if its true this particular layer builder could behave as proposed by seanleblanc.

What do you think?

Regards, Stefan

[StefanGoldmann]

chanseokoh

Hello again, I have extended seanleblanc approach and extended it such that the user needs to explicitly
enable retaining of symbolic links. That way, everything should stay backwards compatible.

I am totally new on github and don't really know how to proceed now. Any advice appreciated.

Anyway, if you like, give it a look. Tests are pending yet ...
StefanGoldmann@3218679

[putsev]

@StefanGoldmann Could you create another Pull Request with your changes, please?

[StefanGoldmann]

I'm on vacation, but will do in 2 weeks. Regards, Stefan Andrew Putsev ***@***.***> schrieb am Mi., 7. Feb. 2024, 11:11:

…

@StefanGoldmann <https://github.com/StefanGoldmann> Could you create another Pull Request with your changes, please? — Reply to this email directly, view it on GitHub <#3506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4V4XECBDN5HMASGJBYIUFLYSNHOPAVCNFSM5IDH2YWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGE3TAOBVGUYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[StefanGoldmann]

@putsev Sorry for the late response, pull request now created (#4233)