Bug #105327
open
PackageArtifactBuilder creates junctions on windows, incompatible with Docker Desktop
0%
Description
Follow up for #100282 #101871 #103898.
Scenario
Windows 10 with development mode set. LAMP stack using Docker Desktop.
Resulting symptoms
PHP in the docker container cannot resolve junctioned assets.
The resulting symlink viewed from docker is an absolute path wich does not exists inside the container.
Workaround
Running a powershell script replacing the Junctions by Symlinkd.
However, now composer complains.
* Could not publish public resources for extension "typo3/cms-core" by using the "junction" strategy. Check whether the target directory "./html/_assets/1ee1d3e909b58d32e30dcea666dd3224" already exists and Composer has permissions to write inside the "_assets" directory.
Suggestion
On Windows, try symlinking, on failure, try junctioning. Maybe also save the symlinking failure if junctioning works during the execution.
Updated by Chris Müller 3 months ago
- Related to Bug #100282: Enable _assets Symlinks (junctions) on Windows added
Updated by Chris Müller 3 months ago
- Related to Bug #101871: PackageArtifactBuilder still tries to create symlinks on Windows added
Updated by Chris Müller 3 months ago
- Related to Bug #103898: Existing "_assets" subdirectories not being a symlink prevents installation added
Updated by Garvin Hicking 3 months ago
Just to understand this: You are running composer commands outside the docker container, on your host? Would anything speak against running composer inside the container? I believe then symlinks should be created which should also work outside of the container in the mounted volume?
Updated by Pierrick Caillon 3 months ago
Yes, it is run outside the container. Because there was issues previously in asking to create a symlink from the container or virtual machine.
Updated by Garvin Hicking 3 months ago
Which issues do you face when running composer within the container? This would be also recommended to use the container's PHP environment and filesystem lookups. On several places, PHP/composer will believe it runs on Windows and make false assumptions.
Updated by Pierrick Caillon 3 months ago
Our template docker environment does not ship with composer. And I would like to keep being able to run it in either if I put composer in the container. Symlinks are created ok from container.
I have not yet encountered any filesystem path resolution issue when running in this setup.
We could always use some script to convert the junctions to symlinks. However, it should not be reported by a warning as it is still an indirection to the real folder, and the right one. Thus not needing the warning implemented in #103898.
Updated by Garvin Hicking 3 months ago
I believe this kind of setup will lead to trouble along the way, and conferred with another developer about this. Composer internally for example also makes use of junctions.
If we adapt to create symlinks here, these have drawbacks on "real" Windows-setups, and will create different trouble. So probably the decision to use symlinks or junctions would need to be configurable for different scenarios, adding complexity and maintenance.
Executing/operating composer in an environment that is not the "actual" environment will always be a conceptual problem. So I really think you should regard your container operations more like a deployment scenario.
You would prepare the data on the host, but for usage inside the container, you would apply customization like when deploying a composer-packaged installation to a webhosting instance. This could then decouple your container-based instance from the host-instance and ensure compatibility.
IMO currently it is a "good thing" to make the TYPO3 application emit a mismatch warning at this place. It's only a warning message / hint and not a failure, so in your case this would be something you could/should ignore while working with the instance.
What do you think?