/.travis/functions: No such file or directory

Travis CI Discussions & Feedback
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 Travis CI - Test and Deploy with Confidence

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 Environment Variables - Travis CI.

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
13

The problem seems to have two parts. First, Travis defines a custom .bashrc that requires the “TRAVIS_HOME” environment variable to be explicitly defined, or else the above error is thrown. The other issue is any code that executes shell commands has to explicitly pass through the inherited TRAVIS_HOME, or else the error happens. Since most people don’t target Travis as their production environment, most people don’t think to define the TRAVIS_HOME environment variable.

The solution for me was to update my Tox configuration to whitelist TRAVIS_HOME so it gets passed to my tests. That’s fixed most of the errors, but there are still a few calls within my code that make additional calls to a shell, which are harder to fix since there’s no explicitly support for passing through specific environment variables.

A better solution would be if Travis just updated their .bashrc so that if TRAVIS_HOME isn’t defined, then default it to /home/travis. That seems a lot simpler than requiring all users to patch their code.

14

Passing through any environment variables that a tool does not specifically manage is standard practice specifically because of this. If tox violates this practice, that’s tox’s problem.

The impact of this violation is not limited to TRAVIS_HOME. Any envvar that alters the behavior of any external shell commands used would have the same effect.

The implication here is that a local sysadmin knows better than a tool how their system should operate. For behavior consistency purposes that tox pursues, tests and the tested software shouldn’t use any non-tox-managed envvars, only external software may.

Under the current circumstances as you described them, whitelisting the envvar was the right thing AFAICS.