Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs or on the blog for current information.

This post details how to automate running a build daily on CircleCI.


A few weeks ago, I set up one such build to check that some Rails dependencies install properly from scratch. You might want to do something similar to check the status of a build over time. To match this example, you will need a separate unix or linux server running cron to kick off the builds each day.


Create a commit in your repository that you want to run regularly, then push it to Github. I made a branch in a simple Rails app called “unpinned_dependencies”. Its purpose is to check that the latest stable versions of the following gems will install correctly:

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug'
  gem 'rspec-rails'
  gem 'capybara-webkit'
  gem 'rspec_junit_formatter'

Generate a Token

Project Settings -> Permissions/API Permissions -> Create a token with a label This will need the “All” permission to trigger builds:


I recommend putting this token in the project UI, under environment variables. Your token will only be on CircleCI. Compare this to storing a token in a commit, which will be on your dev machines, on Github, CI and your production machines. For this example, it’s stored as CIRCLE_REPO_TOKEN.


Figure out the right CircleCI API endpoint for your build, and put it in a script.

# /bin/sh

curl -X DELETE \
      --header "Content-Type: application/json" \
      -d "{}" \

curl -X POST \
      --header "Content-Type: application/json" \
      -d "{}" \

Note the first delete request. For the purposes of this project, I want to make sure all dependencies can install from scratch, so I’m first deleting the project cache. This is a crude approach, as the clear-cache API removes the cache for all branches. If this repo is shared with anyone else, this will affect their builds on other branches, slowing them down once a day.

A more fine-grained approach would be to use circle.yml delete cache folders if the branch matches a certain name. You could also make a separate repo just for running regular tests. I’ve done that with this example, to demonstrate the simplest possible use-case.

Automating the build

I use cron on an Ubuntu box for this example. I simply copied into /etc/cron.daily/. This doesn’t give me control over what time of day the script runs, which is okay for this build. If you want more granularity, you can create an entry in crontab to kick off

Slack integration on CircleCI to notify results

Visit “Project Settings” -> “Notifications/Chat Notifications” -> “Slack Integration”


Click through the “CircleCI Integration” link to login and choose a channel or person to message. I’ve used this step for both notifying a room and notifying myself, depending on what I’m exploring.

That’s pretty much it. You can test this whole flow by manually executing the script once. If you see a slack message like the following, then you’re good to go.

This was a relatively simple example, but after I’ve gone through this once, it’s given me ideas for other ways to extend this behavior. Perhaps in a future post I’ll write about building on top of these tools to find flakey errors. If you have any tips or tricks on how you maximize CircleCI for your team, let us know about it on Discuss.