40

One used to be able to download Vagrant boxes to debug Travis builds (for GitHub projects for instance). Apparently, this is no longer possible, so how do people currently debug complex Travis build chains locally?

Community
  • 1
  • 1
BenC
  • 8,729
  • 3
  • 49
  • 68
  • [The answer in the question you linked to](http://stackoverflow.com/a/17133843/1267663), does it not help? – Whymarrh Feb 03 '14 at 02:51
  • @Whymarrh: this seemed like a temporary "solution" that relies on the availability of the Travis CI team. Often, debugging Travis builds that use tons of automatic features (e.g. coverity report + documentation upload) requires several debugging steps, so having the VM on your machine makes things much, much easier, and usually faster since the build itself can take over half an hour. – BenC Feb 03 '14 at 10:12
  • Possible duplicate of [How to reproduce a travis-ci build environment for debugging](http://stackoverflow.com/questions/29753560/how-to-reproduce-a-travis-ci-build-environment-for-debugging) – Jonathan Hall Mar 16 '17 at 17:03
  • Any reason you don't just put Travis in debug mode and log in remotely? – iconoclast Mar 02 '19 at 19:32

3 Answers3

7

One way to inspect the build (not to debug, sorry) is to send the build logs to another server on failure.

Here is an example:

after_failure
  - sudo tar -czf /tmp/build-${TRAVIS_BUILD_NUMBER}-logs.tgz your-application-logs/
  - scp /tmp/build-${TRAVIS_BUILD_NUMBER}-logs.tgz travis@your-server.com:~/logs

You could send them via email, store them on a storage server or whatever.

These logs would be useful to you if you run your tests in a debug mode and include our own logs as well in the tarball.

Haralan Dobrev
  • 7,617
  • 2
  • 48
  • 66
  • 7
    I already check the logs on Travis, this is how I debug builds **remotely**, but fixing builds involves commiting blindly for intricate errors, and waiting for Travis servers. This is not ideal for complex build chains, hence my question about **local** debugging possibilities. – BenC Feb 14 '14 at 14:15
  • So you're left with reducing the problem instead of finding a solution. Try to minimize the build time and build steps (you could divide the project into separate repos with separate Travis builds). Try to have a dev environment very similar to that on Travis. – Haralan Dobrev Feb 14 '14 at 14:27
  • This is why having virtual machines with Travis systems is a nice way to debug builds locally. This was possible, but not anymore, unless you are ready to replicate the exact system on another VM (e.g. Virtualbox). – BenC Feb 14 '14 at 14:42
  • @BenC You could use their cookbooks with whatever VM you prefer. https://github.com/travis-ci/travis-cookbooks – Haralan Dobrev Feb 14 '14 at 14:44
6

Unfortunately, there is no good solution for testing travis-ci builds locally at the moment. The closest thing I can recommend is a Ubuntu 12.04 vagrant vm and to provision it with the Travis chef cookbooks from here. This will solve most use cases as most of the time the test failures are not from the travis software (Though when it is you're in tough luck, as most Travis software depends on the other pieces of Travis software, making it fairly difficult to set up) but from the underling OS (Ubuntu) and software such as ruby and ruby gems.

joshua-anderson
  • 4,458
  • 5
  • 35
  • 56
3

I had a crack at making a docker file for JVM builds here which works well for me. It is based of the travis published containers and utilises the Travis CLI and Travis Build projects to be able to run your .travis.yml file within a docker container.

A built JVM image is on docker hub.

tellisnz
  • 548
  • 4
  • 10