Cameron Macintosh

In my day job, I was recently working on our deployment pipeline, but I kept getting stuck running the API locally. Basically, the API does a git-pull, figures out what changed, then only compiles those classes.

As it turns out, the server environment runs under the system user and doesn’t know about my ssh credentials. Enter the sshCommand config option!

This is the nature of maintaining software.  You step into a role and are handed a repository of code.  There may be a lot of it, and it’s quality is questionable at best.  There may even be a ton of cruft.  I recently encountered one such repo involving a 7 year old WordPress Multisite. Additionally, there were a number of custom database tables and php CRUD apps were built alongside & intertwined with this MU instance.  About a year before I joined the project, the old Multisite instance became the basis for a new website, and a number of themes, plugins, library code, and log files were unnecessarily added to the new repository.  Even if one performs git rm, those files will still remain in the history and would be downloaded with every new clone.  Since it was still relatively early enough in the project’s history (and that I was the only active developer), I decided to try some more advanced git magic to purge these files.