I have a test script that gets called in .travis.yml:
script:
- ./test.sh
This test script is run whenever a commit is pushed to a repository. This is a bash script in which I create a temporary directory, add a trap to remove that directory when the script completes, and do some work:
#!/usr/bin/env bash
set -o errexit
TMPDIR=$(mktemp --directory --tmpdir=${HOME})
trap 'rm -rf "${TMPDIR}"' EXIT
# ...some work...
What causes problems is that trap call.
When the tests pass, the script exits successfully with status code 0. The EXIT trap is triggered, which begins an attempt to delete ${TMPDIR}.
This attempt fails due to permissions errors, e.g.:
rm: cannot remove ‘/home/travis/tmp.uaFEDOAgQt/.../log/error.log’: Permission denied
rm: cannot remove ‘/home/travis/tmp.uaFEDOAgQt/.../log/access.log’: Permission denied
The command "./test.sh" exited with 1.
The script runs processes as the Travis environment user. Those processes create these (log) files. Those processes are not run as other users. Since the processes are started by the Travis user, those directories must be owned by the Travis user, and so it should be possible to remove them. However, they cannot be removed.
This is not an issue if I run the test script locally. This only occurs as an issue within the Travis CI build environment.
One solution is to disable the trap. What might be other solutions? Can I add sudo to a command run within a (trusty) Travis environment, without the script being prompted for a password? I suppose a sudo call should override permissions complaints, but it's not clear why that should be an error in the first place.
