I’m releasing all my projects through continuous integration, so I end up working with Travis-CI a lot. Travis provides a corresponding diagnostic page for each project I have linked to it from GitHub. For example one of my GitHub projects is here and its Travis-CI subpage would be here. If you look at the link format, you’ll understand what I mean. In there you can see what the output of your job was. Most of the jobs are fairly simple and finish within short period of time. For these jobs debugging the build steps is easy: just look at the console output and see what’s wrong. It’s what I do 95% of time. Below I give hints on how to handle 5% of other cases.
While working on Sensorama for iOS I had to do something different, since it generates a lot of output from many tools. It has many dependencies on Ruby Gems and CocoaPods, which make it long-running as well. Unless you’re careful, you’ll make your life and Travis job debugging harder. For me debugging OSX/iOS projects is especially challenging, since it’s a flow of: bug, commit, verify cycles (for Linux/UNIX projects you can run Travis-CI environment in a Docker container).
Travis-CI is entirely free for Open Source, which I find great. Even though its run-time limits are pretty generous, they do exist:
How does the issue look like?
Example (from here):
+scan --workspace Sensorama.xcworkspace --scheme SensoramaTests
[08:12:08]: xcrun xcodebuild -list -workspace Sensorama.xcworkspace
No output has been received in the last 10m0s, this potentially indicates a
stalled build or something wrong with the build itself.
The build has been terminated
Another one (from here):
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.3.sdk -fasm-bloc
The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
The job has been terminated
How to deal with this stuff?
For XCode projects just pipe everything what comes from xcodebuild through
xcpretty. If you’re using fastlane
(and if not, you should), then the xcpretty is used automatically.
Normally I don’t like the tools which obfuscate real command’s output, but
in this case I had no choice. Also xcpretty makes the output
understandable.
Travis-CI has this cool undocumented feature called “output folding”. You can group lines of output which belong to the same group of commands. You’ll get them folded together and you don’t have to scroll through all the output thanks to it.
How to do it?
First of all, your config file .travis.yml for the script entry has to
call 1 script. So for Sensorama I have:
language: objective-c
osx_image: xcode7.3
cache: cocoapods
rvm:
- 2.2
podfile: Sensorama/Podfile
script:
- ./scripts/travis_script.sh
#- ./scripts/script_with_folds
addons:
ssh_known_hosts:
- gitlab.com
If you want to give it a try, use script_with_folds, borrowed from here.
Then it’s pretty easy:
#!/bin/bash
travis_fold() {
local action=$1
local name=$2
echo -en "travis_fold:${action}:${name}\r"
}
travis_fold start foo
echo "This line appears in the fold's 'header'"
echo "Stuff inside"
sleep 2
echo "More stuff"
travis_fold end foo
So every fold has to start with travis_fold:ACTION:name, where ACTION is
either start or end, and the name is whatever you want.
For Sensorama I plan to use output folding a lot, so I’ve devised a simpler way to deal with this stuff:
TMP=/tmp/.travis_fold_name
# This is meant to be run from top-level dir. of sensorama-ios
travis_fold() {
local action=$1
local name=$2
echo -en "travis_fold:${action}:${name}\r"
}
travis_fold_start() {
travis_fold start $1
echo $1
/bin/echo -n $1 > $TMP
}
travis_fold_end() {
travis_fold end `cat ${TMP}`
}
This is a more elaborate version of what I showed before, but it lets you to do:
(
travis_fold_start BOOSTRAPPING
./build.sh bootstrap
travis_fold_end
)
Without worrying whether the start and end tags for the fold are matched.
One of the stupid mistakes I’ve made in one of the commits is that action
and name mismatched, and then folding is broken.
For optimizing output logging I’d start from trying to limit job output. In cases where you can’t do it, try to use some output “compressors” and prettyfiers. Remember that these things add complexity and can sometimes make debugging harder, as they essentially obfuscate the output of original commands. At the end use output folding on Travis-CI.
Was this article useful? Let me know