Mirroring repositories locally to deployer

[REBELinBLUE]

Last night I changedDeployer so that it mirrors the git repository in the project directory as mirror.git, then when you deploy it updates that and then does a shallow clone using that as the source.

That way you don't have to continually download the same files everytime you deploy, only files which have updated.

This obviously means the initial deploy is slower, and it uses more space on the server but later deploys are faster and transfer less data

However, I still have to check it out locally to the Deployer server in order to get the commit info.

So I was thinking, instead have mirrors of the repos on the Deployer server; and instead have Deployer tar up the last commit, transfer it to the server and untar it rather than running git on the server

Having a mirror means the rollback is actually possible, and having it on the Deployer server means I can show a list of branches and tags rather than just text fields

So what do you think?

It obviously means the Deployer server will take up more space though

(Obviously getting a specific revision, list of tags/branches and the commit info without cloning the repository is doable with the APIs for gitlab, github and bitbucket but I want to support all types of git repositories if possible)

• Mirror the repositories to storage/app
• Update installer to check tar command exists
• Update deploy process to clone from the mirror locally, then tar the revision to be deployed then scp to the remote server & replace the "Clone new release" step
• Rename the "Clone new release" step?
• Change scp command to rsync so we can get progress
• Update deploy process to untar the file and delete the archive
• Use select2 on deployment dialog for dropdowns
• Update project deletion to remove mirrors
• Update project editing to remove mirror if repo is changed, could try renaming and changing the remote?
• Add a cronjob to remove orphan mirrors
• Add a cronjob to update mirrors
• Use the mirrors to get a list of tags and branches
• Update the deploy dialog to show branches and tags
• Implement rollback using the mirrors
• Implement deploying a specific revision, needed for rollback
• Refactor DeployProject, getScript should NOT be uploading files Not going to do as part of this PR
• Ensure it is clear what the error is if there is a problem when cloning the repository
• Ensure the transfer times are included in the runtime

[REBELinBLUE]

[REBELinBLUE]

Quick test, a deploy which takes 75 seconds currently took 28 seconds. Will need to test it at work with large/slow repositories

[REBELinBLUE]

This branch is basically finished, I am using it at work right not to test it, but if anyone else fancies trying it out such as @dancryer please do :)

[lorvent]

This is great, today i can see huge improvement in deployment times in "Install Composer Dependencies" step.