CircleCI Libsass Configuration

circle.yml

dependencies:
  cache_directories:
    - sassc
    - libsass
  post:
    - if [[ ! -e sassc ]]; then git clone [email protected]:sass/sassc.git sassc; fi
    - if [[ ! -e libsass ]]; then git clone --recursive [email protected]:sass/libsass.git && cd sassc && export SASS_LIBSASS_PATH=$(readlink -f ../libsass) && make && cd ..; fi
    - ln -s sassc/bin/sassc ~/bin/sassc 

This is a chunk of configuration to drop in to a CircleCI YAML file (see here for configuration documentation). This pulls down SassC and Libsass manually from their respective Github repositories and sets them up to be followed up with something like node-sass to compile Sass files with Libsass.

The cache_directories stanza ensures that the Git clone process doesn't need to take place for every single build.

At Jolby we hook into the deployment stanza where we would run an NPM script to build the CSS. Something like this would sit in package.json:

{
  "scripts": {
    "build:css": "node-sass ./app/static/scss/app.scss --precision 7 --stdout --include-path ./node_modules/ | autoprefixer -o ./app/static/build/css/app.css"
  }
}

And in our circleci.yml we would add something like this:

deployment:
  staging:
    branch: master
    commands:
      - fab staging build:$CIRCLE_BUILD_NUM deploy:$CIRCLE_BUILD_NUM

The fab ... command leverages Fabric, running a staging command to point any subsequent commands at staging server(s), followed by a build command that would trigger npm run build:css, along with other build process such as Javascript compilation, followed by a deploy command that sends over the bundled up build artifacts to the server via rsync or something similar, followed by a restart or something along those lines.