I am currently a single point of failure for getting code from our Github repo to WordPress.com VIP SVN. As such, we (Fusion) are exploring a project to auto-deploy our Github repository to VIP SVN through post-CI middleware. But, before we dive into development, we want to make sure we’ve exhausted all lower-effort options.
How does your code get from Github to VIP SVN? Would you potentially want ot use our project? Please let me know with a comment — thanks!
9 Comments
Since VIP (and plugins in the .org repo) are the only things we use SVN for, we use Git internally for storing the code and commit via Cornerstone when it’s time. We have also been exploring setting up an automated way of doing so, hence I’ll be watching this thread closely as well.
I’ve used Git inside of SVN and Git SVN before, personally I found Git SVN is a lot easier. However, they’re still not ideal.
I haven’t seen any alternative methods for this. I’d love to see an auto-deploy tool!
My commits are 100% handcrafted. Pull from Github, commit a few files at a time to VIP (using Versions as a SVN client). I think it’s worth it to take a couple minutes to send a batch of more granular commits that are easier for the reviewer to approve.
Automation sounds good in theory, but our workflows are designed for writing code, not reviewing it.
If, say, every merged pull request on Github generated a single SVN commit, a lot of those commits would be a mishmash of features that would be much harder to review than if the same changeset was broken into smaller chunks.
I’ve written a script that commits to SVN for a checkout inside of a Git repo. The script creates a
vip-committed
tag each time it does a commit, and then the next time I do a push to VIP, the commit message is crafted that includes the HEAD commit hash, followed by agit shortlog -sne
for a list of the commit authors, and then oneline commit log (without merge commits). It’s basically a git squash merge.This has been working well, although it does not take into account any upstream VIP hotfix commits, and it does not play nice with Optimizerbot, so I
svn revert
any image changes at the time of committing.An SVN commit for each merged pull request is also what I’ve been considering.
What language is the script in?
Bash.
Like others, pull down Git, commit in chunks via Cornerstone. It’s entirely risky because I’m 1) being concise with my commits as to make them logical and easy to review, but 2) if the reviewer is trigger-happy they may deploy half of the commits I needed and take a while to get to the second half.
It was talked about over a year ago that they would introduce a Deploy button in the dashboard: they’d review all SVN commits and flag the commits as reviewed somehow and then let the client deploy in their own time. I haven’t heard anymore on that, but if/when this is ever introduced it solves the biggest problem, IMO.
If you leave a note in the commit, like
Commit: 1 / 6
Regular commit message here
We can not deploy stuff when we see that there are more coming 🙂
We do all our development in Git. When I’m working on code, I keep a separate SVN repo, rsync the changes over, and then manually review the code before committing. The reason for this is to prevent accidental code from slipping in (that’s mostly paranoia, but we do merge our development branches into the master branch in git, then copy from the master branch to SVN, sometimes we find code that’s slipped into master, doing this process manually helps us catch that rogue code and occasionally we find stuff that should have gone into production and never did).
We’d like to automate the process, but we want to get better about writing unit tests first.