Scheduling regular Travis CI builds with Cron Jobs

If you have a project of any complexity that is using Travis CI for testing, you’ve inevitably run into an issue where you make a minor change – maybe even just to a markdown file – and the tests that were passing before completely bomb. If this hasn’t happened to you, just wait, it will! This typically happens because some dependency, such as a newer rubygem you depend on indirectly, is no longer compatible with your test environment. As an example, I updated my .travis.yml in a puppet module project, opened PR16 , and suddenly all the previously-green tests went red . The error NoMethodError: undefined method 'last_comment' for #<Rake::Application:0x000000015849f8> was observed because the dependent gem rake was updated from v11 to v12 , conflicting with the pinned version of rspec . Until this problem is fixed, every PR, no matter how simple or complex, is going to fail its test.

This puts a lot of burden on both the person submitting the PR, who just wants their simple change to be approved, and the project maintainer, who wants their build status to work. Neither is satisfied until the problem is tracked down and remediated, often in a separate PR. By that time, the contributor may not have the interest to update their PR and the maintainer has to decide if they want to fix it up or discard it. No-one is happy. All because some upstream dependency changed and we weren’t aware of it until the moment a PR was submitted, even though it may have happened days or months ago.

Fortunately, Travis CI recently provided a way to help address this common issue! It’s called Cron Jobs and let’s you schedule builds on a regular basis. If a project does not have PRs submitted against it on a very regular basis, it needs some other way to regularly validate the current test environment, including updated dependencies, in order to flag issues with it rapidly. The documentation is pretty straightforward on how to implement the cron job. You can only add one cron job per branch, so my recommendation is to create a daily job against the default branch with the option to always run. There is an option Do not run if there has been a build in the last 24h , but that actually results in one run per 48 hours (runs at 0:00:00; when it runs at +1:00:00, it sees the job from 24 hours prior and skips; runs again at +2:00:00; skips +3:00:00; etc). Here’s what that looks like:

Next, you want to ensure your cron jobs notify you if they fail. If you have not modified the email notification settings from the default, you’re going to get an email on every build anyway. If you have silenced emails entirely or in part, you want to make sure that on_failure is set to always . For me, this meant changing a few lines in .travis.yml , as seen in PR16 :

diff --git a/.travis.yml b/.travis.yml
index cfaaa1c..f061c18 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,7 +3,8 @@ language: ruby
 sudo: false
 cache: bundler
 notifications:
-  email: false
+  email:
+    on_failure: always
 branches:
   only:
     - master

You can read more about Travis’s email notification options here .

Scheduling a Travis CI cron job should help you identify new issues in your test environments and fix them immediately, before contributors run afoul of problems, which should be helpful for most projects and maintainers! You can also use this to automate nightly builds and plenty of other creative uses, as well.