Circle CI - (part 1)

Circle CI

CircleCI gives web developers powerful Continuous Integration and Deployment with easy setup and maintenance. Simply connect your GitHub account and CircleCI can run tests on your Ruby, Python, Node.js, Java, and PHP projects. CircleCI support authentication with GitHub and Bitbucket.

Started with CircleCI

Setting up CircleCI usually takes only three mouse clicks:

• Sign up with CircleCI.
• Give CircleCI permission to access GitHub or Bitbucket on your behalf.
• Click on a project.

The reason it’s so easy is that CircleCI automatically infer user settings from users code. CircleCI expect user to have a project that roughly follows best practices for users platform. If user do, user tests will be up and running in a flash.

Of course, life is not always sunshine and daisies. Sometimes user tests will fail, CircleCI won’t infer user custom setup, or CircleCI inference won’t be aware of your test suite. Here are some common issues and where user can find their fixes.

• If we didn’t run an important step or omitted some tests, add a circle.yml file to tweak your test run.
• If we didn’t infer anything, you can set up your project manually.
• Sometimes, your tests will fail on our server even though they work locally. Read CircleCI list of common problems and their solutions.

Testing is no fun if you’re the only one playing. To add your colleagues, simply ask them to join CircleCI. CircleCI use GitHub or Bitbucket permissions for all projects, so if they have access to your project on GitHub or Bitbucket, they’ll have access on CircleCI, too.

One of the best things about CircleCI’s design is that user have own account, which in turn enables CircleCI to send personalized emails only for the branches user use.

No matter if you commit to a project only once a month or if a project is just getting started, adding it to CircleCI will help keep it on track. Adding a project refers to the first time the project is setup on CircleCI.

Configuring CircleCI

CircleCI automatically infers your settings from your code, so CircleCI’s normal processing works just fine in most circumstances. When it doesn’t, the circle.yml file makes it easy to tell CircleCI what you need. This is a simple YAML file where you spell out any tweaks required for your app. You place the file in your git repo’s root directory and CircleCI reads the file each time it runs a build. Here provide one complete sample circle.yml file.

## Customize the test machine
machine:

  timezone:
    America/Los_Angeles # Set the timezone

  # Version of ruby to use
  ruby:
    version:
      1.8.7-p358-falcon-perf

  # Override /etc/hosts
  hosts:
    circlehost: 127.0.0.1
    dev.mycompany.com: 127.0.0.1

  # Add some environment variables
  environment:
    CIRCLE_ENV: test
    DATABASE_URL: postgres://ubuntu:@127.0.0.1:5432/circle_test

## Customize checkout
checkout:
  post:
    - git submodule sync
    - git submodule update --init # use submodules

## Customize dependencies
dependencies:
  pre:
    - npm install coffeescript # install from a different package manager
    - gem uninstall bundler # use a custom version of bundler
    - gem install bundler --pre

  override:
    - bundle install: # note ':' here
        timeout: 180 # fail if command has no output for 3 minutes
        # IMPORTANT NOTE: ^^ the timeout modifier above must be
        # double indented (four spaces) from the previous line

  # we automatically cache and restore many dependencies between
  # builds. If you need to, you can add custom paths to cache:
  cache_directories:
    - "custom_1"   # relative to the build directory
    - "~/custom_2" # relative to the user's home directory

## Customize database setup
database:
  override:
    # replace CircleCI's generated database.yml
    - cp config/database.yml.ci config/database.yml
    - bundle exec rake db:create db:schema:load

## Customize test commands
test:
  override:
    - phpunit test/unit-tests # use PHPunit for testing
  post:
    - bundle exec rake jasmine:ci: # add an extra test type
        environment:
          RAILS_ENV: test
          RACK_ENV: test

## Customize deployment commands
deployment:
  staging:
    branch: master
    heroku:
      appname: foo-bar-123

## Custom notifications
notify:
  webhooks:
    # A list of hashes representing hooks. Only the url field is supported.
    - url: https://someurl.com/hooks/circle

File structure and content

The circle.yml file is made up of six primary sections. Each section represents a phase of running your tests:

• machine: adjusting the VM to your preferences and requirements
• checkout: checking out and cloning your git repo
• dependencies: setting up your project’s language-specific dependencies
• database: preparing the databases for your tests
• test: running your tests
• deployment: deploying your code to your web servers

The circle.yml file contains another general section for general build-related configurations that are not related to a specific phase, and an experimental section for early access previews of configuration changes under consideration. Most projects won’t need to specify anything for many of the phases.

The sections contain lists of bash commands. If you don’t specify commands, CircleCI infers them from your code. Commands are run in the order they appear in the file; all test commands are run to completion, but a non-zero exit code during the setup sections (machine:, checkout:, dependencies:, database:) will cause the build to fail early. You can modify which—and when—commands are run by adding override, pre and/or post to adjust CircleCI’s inferred commands. Here’s how it works:

• pre: commands run before CircleCI’s inferred commands
• override: commands run instead of CircleCI’s inferred commands
• post: commands run after CircleCI’s inferred commands

Each command is run in a separate shell. As such, they do not share an environment with their predecessors, so be aware that export foo=bar in particular does not work. If you’d like to set an environment variable globally, you can specify them in the Machine configuration section.

You can tweak individual commands by adding a modifier. Allowed modifiers are:

• timeout: if a command runs this many seconds without output, kill it.
• pwd: run commands using this value as the current working directory.
• environment: a hash creating a list of environment variables set for this command.
• parallel: (only used with commands in the test section) if you have manually set up parallelism, set this to true to run a command across all VMs
• files: The files identified by the file list (or globs) will be appended to the command arguments. The files will be distributed across all containers running the build. Check manual parallelism setup document for more details.
• background: when “true”, runs a command in the background. It is similar to ending a shell command with ‘&’, but works correctly over ssh. Useful for starting servers, which your tests will connect to. Note that YAML is very strict about indentation each time you add a new property. For that reason, modifiers must be indented one level from their command.

Related referance - https://circleci.com