Search code examples
gitcapistrano

Capistrano — add a task to update repo from server before deployment if server version is newer


So I am using Capistrano (v2) to deploy websites built with Perch (grabaperch.com). When a user (on the live server) creates a 'page' in Perch, the system creates an actual .php file with an include for whatever 'master page' that page uses. Obviously, this causes the repo to be out-of-date.

To solve this, I was wondering if I could use one of Capistranos hooks to check the status of the files on the server and prompt the user to choose to:

a) update the repo by pushing the new files back in to the repo

b) ignore (not sure why but this may be useful)

Furthermore, this could (possibly?) be done on a per-file (or folder) basis to give more control over what ends up being version controlled.

Being a relative newcomer to Capistrano and Ruby — I don't have much of a clue how or if this can be done.

So my question, is this:

a) a good idea

b) possible

c) if (a && b) how?

(apologies if this question/s is not specific enough for SA — I don't know where else to ask it)


Solution

  • Well it might be possible but you will work quite hard to make it happen.

    You'd need a task before the one which checks out the repository that will check the current dir for changed files.

    You can use git ls-files . --exclude-standard --others for untracked and git ls-files -m for modified files, if there's input you'd have to commit those files and push them into the repository. If you've done it before capistrano checksout the latest master then it now will checkout the newest master with your new files.

    Now if you'd like the ability to control which files to add to the repo and which not to you can either have your .gitignore configured correctly or you can use the output you get back from git ls-files with some other gem like highline, maybe this will help you (capistrano used to have a CLI module in the DSL but it's gone).

    So yeah it's possible.

    Should you do it?

    It depends if there are any implications from Perch. I've never used Perch before so I partly understand why they create the extra files, moreover you'd also have to check for files that have been deleted (incase that Perch deletes pages that the users no longer use) or you will have trash in your git repository (in the good case) and in the worse case you'd have data inconsistencies which is BAD.

    Hope this helps.