aws-codedeploy-agent
aws-codedeploy-agent copied to clipboard
aws
Sym Links not preserved during deployment
OS: Linux agent_version: OFFICIAL_1.0-1.1458_rpm
I am giving the code deploy agent a pre-zipped file uploaded to s3 for deployment which contains a number of relative symlinks a few directories deep (using zip -ry). I confirmed that the artifact is unzipped correctly on the server and all symlinks are there in the deployment-root, but during the copying of the files from the deployment-root to the app directory, the symlinks are replaced with the actual contents instead of preserving the symlink.
I believe this has to do with the use of Ruby's FileUtils.copy() instead of FileUtils.copyEntry() but have not tested the change yet.
@bryantcj52 is it something that happened with previous version of agent too, or did you just notice it happening with 1458?
@bryantcj52 is it possible to share a dummy zip with folder structure like this , so that we can try to reproduce this on our end?
@rohkat-aws
https://www.dropbox.com/s/7u8zo64nedqp5n8/test-app.zip?dl=1
Here's a small example of the directory structure and sym links.
This appears to be happening with our deployments as well. We are using GitHub as our repo. Our symlinked directories are now being filled with the actual contents of the symlinked folder instead of the symlink. I'm not sure how long this has been happening, but I checked my repo to make sure that they were symlinked directories.
so i did try running it using the copy entry command,but some of the tests fail too. Will need to look into them before including it in the code. @bryantcj52 @luciddev
How is this not higher priority? Why does the aws deploy push command do the same thing? Code build does this too. Why is AWS bent on destroying our intended file structure that includes symlinks?
Beanstalk doesn't do this, thankfully.
@et304383 its still a high priority and though it might seem an easy fix, its not ,because the tests after the change is breaking. So we are looking into it.
This particular problem comes up for me with PHP-based applications (e.g. Drupal). Because we require scripting tools that are installed via composer in vendor/bin after the deployment is placed on the server. All composer-installed bin files are symlinks to their real scripts, but with codedeploy they're all broken.
@quicksketch us too. This is the exact use case that the Code Deploy agent breaks.
We had to resort to bundling a fix symlinks script as part of our build and adding to our deployment package that in turn gets executed after the package is extracted.
Can we get an update on this please? Symlinks are a basic thing that loads of devs use to avoid duplicating code, this really needs to be looked at ASAP
Saw this as a potential solution, but I think it breaks how the caching works...
https://forums.aws.amazon.com/thread.jspa?threadID=271667
If you use npm > v6, it seems that npm rebuild repair symlink. That could be a good workaround.
So for codepipeline, if you use the full clone option (one with the meta data) of the github source, instead of the "default" option, your symlinks are preserved when you use the source in AWS CodeBuild.
I found a workaround for a nodejs pnpm based application but should work for any kind of application : During the afterinstall phase I run the following:
rm -rf <application-path>/node_modules
cp -r /opt/codedeploy-agent/deployment-root/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/node_modules <application-path>
This will manually copy the directory preserving the symlinks structure.
The two environment variables DEPLOYMENT_GROUP_ID and DEPLOYMENT_ID are available and documented.
<application-path> is a replication (already defined in the appspec on the files section), but is required.
