One feature of our zero-downtime deployment method is the
shared directory. This directory allows you to keep files and folders persisted between deployments, that you don't want to track in your version control system.
Common examples of this might be a log or uploads directory.
Simply move the folders into your shared directory, as a relative path to the rest of your app. Then, on each deployment, we'll symlink the folders across automatically.
They'll look like this:
/path/to/directory/shared/log -> /path/to/directory/releases/20191112000000/log /path/to/directory/shared/subfolder/uploads -> /path/to/directory/releases/20191112000000/subfolder/uploads
This happens if you still have the main xyz directory in your repository, but some of its contents have been removed.
DeployHQ checks each directory in shared to ensure that another (and potentially more up to date) copy of it doesn't exist in the latest release and if it does, it will traverse through any subfolders until it finds a folder or file that isn't present.
It will then symlink those files or folders on an individual basis, which will mean this part of the deployment might take longer than expected. Check to ensure that no folders in shared are in the last release, or your repository, then once any duplicates are removed and committed, try another deployment and you should find that process is quicker.