1

This is where I am running my tests in travis.yml:

# Run tests
script:
  # Test application in Docker container
  - ./tools/docker-test.sh

The shell script docker-test.sh looks like this:

#!/usr/bin/env bash

githash="$(git rev-parse --short HEAD)"

echo "-------------------------------------------------"
echo "| Running unit tests                            |"
echo "-------------------------------------------------"

docker create -it --name test eu.gcr.io/test/test:$githash
docker start test
docker exec test /bin/sh -c "go test ./..."
docker stop test
docker rm -fv test

The TravisCI build is a success even if the tests fail.

How can I get TravisCI to know if test have failed or not? I don't know if this is a problem with errors not being propagated from Docker, errors not being propagated from the shell script or TravisCI not knowing when go tests succeed or fail.

user1283776
  • 19,640
  • 49
  • 136
  • 276

1 Answers1

3

Your script is exiting with the status code of the last command docker rm -fv test.

You need to capture the status code of the test's, then clean up docker, then exit.

This code example is from a slightly different question over here but it's the same solution. 

#!/usr/bin/env bash
set -e

# Set a default return code
RC=2

# Cleanup
function cleanup {
  echo "Removing container"
  docker stop test || true
  docker rm -f test || true
  exit $RC
}
trap cleanup EXIT

# Test steps
docker create -it --name test path
docker start test
docker exec test /bin/sh -c "go test ./..."
RC=$?
Community
  • 1
  • 1
Matt
  • 68,711
  • 7
  • 155
  • 158
  • Why did you move out cleanup to a function? Was that necessary or just a style preference? – user1283776 Aug 05 '16 at 11:11
  • Why have you put parenthesis around docker stop test and docker rm -f test? I understand that those commands are then run in a subshell. What is the advantage of doing that? – user1283776 Aug 05 '16 at 11:14
  • The cleanup function is so no matter what step fails, docker will be cleaned up afterwards via the `trap`. – Matt Aug 05 '16 at 12:13
  • They were a mistake actually. Was looking for a quicker way to skip the `set -e` result checking. `stop` and `rm` should always run without causing the script to exit. – Matt Aug 05 '16 at 12:19