/.travis/functions: No such file or directory

#1

My unittests that check certain OS-level commands are failing with the errors:

[127.0.0.1] sudo: whoami
[127.0.0.1] out: /home/travis/.travis/job_stages: line 1: /.travis/functions: No such file or directory
[127.0.0.1] out: root
[127.0.0.1] out:

AssertionError: ‘/home/travis/.travis/job_stages: line 1: /.travis/functions: No such file or directory\nroot’ != ‘root’

These don’t happen for me on my local Ubuntu install, and they look to be due to some Travis-specific configuration. Any idea how I can resolve them?

#2

When reporting a problem, please include the build log URL, so that we can help you better.

Thank you!

#3

Same problem here.

https://travis-ci.com/ebmdatalab/ebmbot/builds/102161323#L594

Looks like job_stages sources $TRAVIS_HOME/.travis/functions, but for some reason, at the time that job_stages was created, that variable was empty (when it should, in my environment, have been /home/travis).

I found the code that’s supposed to do this here, but not sure why it’s not working.

In my case, the code under test creates a new bash subshell by sshing to localhost, so I guess it’s related to that.

#4

It looks like your code is doing something funny: for some reason, result[HOSTS[0]] has the value /home/travis/.travis/job_stages: line 1: /.travis/functions: No such file or directory.

I guess that your program captures stdout+stderr of some command (and probably does not check its exit code), likely in an altered environment. According to https://en.wikipedia.org/wiki/Standard_streams , a program’s result is supposed to be just stdout contents, stderr is only supposed to be used for diagnostics/error reporting.

You need to track the above-mentioned erroneous value back to its origin along your program’s logic – with debugger or with debug printing. For the former, you can request Travis staff to enable debug mode for your repo as per https://docs.travis-ci.com/user/running-build-in-debug-mode/ .

#5

Here’s my failing build: https://travis-ci.org/chrisspen/burlap/builds/500063221

I’m trying to run “sudo whoami”, and it’s throwing that error. This used to run without error in Travis.

#6

Or, your jobs managed to source ~/.travis/job_stages without $TRAVIS_HOME set. The content of ~/.travis/job_stages should have:

source "${TRAVIS_HOME}/.travis/functions"

See https://travis-ci.org/BanzaiMan/travis_production_test/builds/500078837#L176

#7

Any update on this? I have a lot of code that processes output from shell commands, and this bug is adding Travis-specific junk to everything, breaking a ton of my tests. I can update my code to ignore everything but the last line of output, but it’d be nice if Travis didn’t populate output with irrelevant errors.

#8

Please read my previous comment. Your tool is sourceing the file without the required environment variables set. Please consult your tools (documentation, or if you know the internals, source code). I do not believe this is something we can fix.

#9

I don’t understand your comment. My tool is Fabric, a library for running arbitrary shell commands from Python. How can it source a custom Travis file that neither it nor I know about, much less define a custom TRAVIS_HOME environment variable? If the patch is to manually define TRAVIS_HOME, please document what that value should be.

#10

$TRAVIS_HOME is defined by our build script, and it is exported during the build. This is documented in https://docs.travis-ci.com/user/environment-variables#default-environment-variables.

The file in question /home/travis/.travis/job_stages is designed to be used (sourced) in such an execution environment. And it works.

Something beyond our control is sourceing this file in an inappropriate manner, and causing the issue. It may be Fabric, as you say, or it may not be.

#11

This is probably related to .bashrc or .bash_profile being sourced by the local ssh session, and one of those standard bash files being set-up by travis to source ~/.travis/job_stages, but this ssh session does not have $TRAVIS_HOME set like other forked processes do.

#12

At the end of ~/.bashrc in a travis-ci xenial test environment there is:

...
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

ulimit -n 30000 2>/dev/null || true
source /home/travis/.travis/job_stages

So if you start a new bash shell with a clean environment (which happens when you ssh to localhost as some test systems do), then this error results. I was able to fix this with the following addition to my .travis.yml

before_script:
  - echo "export TRAVIS_HOME=$TRAVIS_HOME" | cat - ~/.bashrc > ~/.bashrc.mod
  - mv -v ~/.bashrc.mod ~/.bashrc
1 Like