Debug mode triggers Python EnvironmentError

Travis CI Discussions & Feedback
,
1

My install step is installing a Python package using Pip. When I run travis_run_before_install then travis_run_install in debug mode (over SSH connection in the tmate session), I get an error. However, when the same job is run without debug mode the build finishes successfully. Is it possible that the two Python environments are not set up in the same way?

This is annoying, because the issue would come up exactly when one is trying to debug something else.

(In my case, the command that fails is python -m pip install tox. I know that adding the --user option might solve this particular issue, but that’s not the point here.)

I set up a GitHub repository and created a PR that demonstrates this issue. See https://github.com/pzahemszky/travis-ci-debug-mode-issue/pull/1.

This issue is similar to the one reported in https://github.com/travis-ci/docs-travis-ci-com/issues/1907 on GitHub.

Operating system: Ubuntu Xenial
Language: Python (3.8)

2 Likes
2

I also have this issue. Did you get a resolution?

EDIT: You --user tip at least allowed me to do some sort of testing.

3

Bottom line: specifically to activate virtualenv for a lang: python build, run travis_run_setup in the debug console.

Exploring a debug session, the debug console runs in a different process tree. It does get the worker Bash’s environment, but Virtualenv’s activate doesn’t export its adjusted PATH so that adjusted PATH is not being trasferred to the console process.

$  pstree -ap | less
  |-sshd,1802 -D
  |   `-sshd,2072
  |       `-sshd,2087
  |           `-bash,2088 /home/travis/build.sh
  |               |-bash,2711 /home/travis/build.sh
  |               |   `-ruby,2765 /home/travis/filter.rb -e SECRET_0 -e SECRET_1 -e SECRET_2
  |               |       `-{ruby-timer-thr},2766
  |               |-ruby,2723 /home/travis/.travis/agent
  |               |   |-{agent:102},2770
  |               |   |-{agent:102},2771
  |               |   |-{agent:102},2772
  |               |   |-{agent:102},2773
  |               |   |-{agent:102},2774
  |               |   `-{ruby-timer-thr},2745
  |               `-travis_debug.sh,3649 /home/travis/.debug/travis_debug.sh --quiet
  |                   `-sleep,4697 1
<...>
  `-tmate,3653 -S /tmp/tmate.sock new-session -d cat /home/travis/.travis/debug_help; /bin/bash -l
      `-bash,3655 -c cat /home/travis/.travis/debug_help; /bin/bash -l
          `-bash,3658 -l
              |-less,4699
              `-pstree,4698 -ap

But, as a workaround, there are convenience functions defined for all build phases, even those not mentioned in the doc:

$ set | grep -P 'travis_run_.*\(\)'
travis_run_after_failure ()
travis_run_after_script ()
travis_run_after_success ()
travis_run_announce ()
travis_run_before_cache ()
travis_run_before_install ()
travis_run_before_script ()
travis_run_cache ()
travis_run_checkout ()
travis_run_configure ()
travis_run_create_workspaces ()
travis_run_debug ()
travis_run_disable_sudo ()
travis_run_export ()
travis_run_finish ()
travis_run_install ()
travis_run_prepare ()
travis_run_reset_state ()
travis_run_script ()
travis_run_setup ()
travis_run_setup_cache ()
travis_run_setup_casher ()
travis_run_setup_filter ()
travis_run_use_workspaces ()

Virtualenv activation is defined in the setup phase of the stock logic, so running travis_run_setup will activate it:

travis@travis-job-9573041d-3363-48b9-aacd-a373d314b597:~/build/native-api/test_travis$ travis_run_setup
$ source ~/virtualenv/python3.8/bin/activate
(python3.8.0) travis@travis-job-9573041d-3363-48b9-aacd-a373d314b597:~/build/native-api/test_travis$
4