Using TravisCI to build and deploy Bedrock and Sage

I am starting a new thread here, as it’s much more TravisCI-focused. I’ll be building this into a blog post as I learn more, but if you’re interested in using Travis as a CI tool for deploying Sage, here are some of the steps so far. You can look at my own Travis status if you’d like, although it’s currently failing due to some bad PHP in my own changes :flushed:

Note: This assumes rudimentary knowledge of TravisCI (when I write the blog post I’ll cover all the setup).

First of all, I based this on the .travis.yml which comes with Bedrock. This will give you nice unit testing of any additional templates, etc, you create.

Here’s my current .travis.yml, and I’ll explain bits and bobs of it at the end.:

sudo: false
language: php
php:
  - '5.6'
  - '5.5'
  - '5.4'

env:
  global:
    - THEME_DIR=./web/app/themes/ado-theme/

  before_install:
    - pyrus install pear/PHP_CodeSniffer
    - phpenv rehash
    - npm install -g gulp bower
    - bundle install

  install: 
      - composer install --no-dev --no-scripts --quiet --optimize-autoloader
      - cd $THEME_DIR
      - npm install --devDependencies --silent --no-spin
      - bower install
      - gulp --production

  script:
    - cd $TRAVIS_BUILD_DIR
    - phpcs --standard=ruleset.xml --extensions=php --ignore=web/wp/,web/app/plugins/,vendor/ -n -s .

First, I set a global environment variable for my theme’s directory. You can replace ado-theme with sage if you haven’t re-named the sage directory in themes. We need this environment variable because a few of our commands need to be run within the Sage directory itself, and this lets us do it once. Yes, at this point I only use it the one time, but it’s nice to have one place to change it.

Next, in the before_install section, we set up some of the global tools we will need. The first two came from the Bedrock .travis.yml, but I added the global installation of gulp and bower, and I also install the gems from our Gemfile which we will use for our capistrano deployment (covered in a later post).

In the install section, I do the actual building of the assets. One might argue that this should go in the script section, and I’m open for debate on this. The items in here include:

  • composer install to get all the composer packages
  • Changing to the theme directory, as our next set of steps need to be run in there
  • npm install (notice the use of --devDependencies, as otherwise gulp will be a sad panda later)
  • bower install to get the bower packages
  • gulp --production which is really our build, so this I could see moving into the script section along with composer install

Finally, in the script section I just added a step to change the directory back to the $TRAVIS_BUILD_DIR so that the phpcs step will run properly against the whole project, and not just the theme. I’ve also added some ignore flags to not test against web/app/plugins because we don’t want our build to fail due to a plugin author writing crappy code.

This is just step one. This will get you a successful build of Sage, and ready to be deployed via Capistrano (which I’ll follow up with in a bit).

Caveats - the npm install --devDependencies --silent --no-spin step occasionally fails with no rhyme or reason, and re-running the build again will make it work. I’ve seen this happen on local servers as well, and I think it might just be a resource timeout?

8 Likes

Bookmarked: when that blog post drops I want to link to it in: http://austinpray.com/ops/2015/01/15/build-steps-and-deployment.html (although feel free to add it yourself :wink:)

I also have a blog post in the works that details e2e how to use continuous integration with travis, bedrock, and sage. Would love to compare notes when I have that written.

1 Like

Did either of you end up posting the referenced CI blog posts. If so, I’m interested in learning more. WP Mock looks interesting.