Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gets stuck in ansitowin32.py on GitLab CI #3534

Closed
sedrubal opened this issue Feb 13, 2019 · 8 comments
Closed

gets stuck in ansitowin32.py on GitLab CI #3534

sedrubal opened this issue Feb 13, 2019 · 8 comments
Labels
reported bug Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided.

Comments

@sedrubal
Copy link

sedrubal commented Feb 13, 2019

Issue description

When running pipenv install or pipenv sync on GitLab CI, pipenv gets stuck (at least for 1h, until the job gets killed).

Expected result

It should not get stuck.

Actual result

--verbose does not print any more information. When LANG is set properly, you can't see any output, otherwise you can read

Warning: the environment variable LANG is not set!
We recommend setting this in ~/.profile (or equivalent) for proper expected behavior.

and after that it hangs.

Steps to replicate

Unfortunately I couldn't reproduce it on gitlab.com. It happens on our private gitlab in a private repo. Here is a minimal version of a Pipfile:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
Django = "<2.2.0"

[requires]
# Don't specify the exact python version, because of https://github.com/pypa/pipenv/issues/1050#issuecomment-346203646
python_version = "3"

I only run pipenv install or pipenv sync.

While the job was running / stuck in GitLab CI, I run the exact same command within the docker container, where the CI job was running and it worked. I think, the problem has something to do with how GitLab CI runs the commands. I thought, the problem might be, that stdout is not a tty, but running something like setsid sh -c 'pipenv install' < /dev/null > log 2>&1 did work, too.

I tried running python3 -m trace --trace /usr/bin/pipenv install > trace_log.txt and this is the output

trace_log.txt

I removed many lines. I think, the last ones are interesting. At the end, it seems, that pipenv is looping forever over:

 --- modulename: ansitowin32, funcname: closed
ansitowin32.py(52):         stream = self.__wrapped
ansitowin32.py(53):         return not hasattr(stream, 'closed') or stream.closed

I already spent hours on debugging, but now, I don't know what to do...


$ pipenv --support

Pipenv version: '2018.11.26'

Pipenv location: '/usr/lib/python3.7/site-packages/pipenv'

Python location: '/usr/bin/python3'

Python installations found:

  • 3.7.2: /usr/bin/python3
  • 3.7.2: /usr/bin/python3.7m
  • 3.6.8: /usr/bin/python3.6m
  • 3.6.8: /usr/bin/python3.6
  • 3.5.6: /usr/bin/python3.5
  • 3.5.6: /usr/bin/python3.5m
  • 3.5.3: /usr/bin/pypy3.5
  • 3.4.9: /usr/bin/python3.4
  • 3.4.9: /usr/bin/python3.4m
  • 2.7.15: /usr/bin/python
  • 2.7.13: /usr/bin/pypy

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.7.2',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.20.7-200.fc29.x86_64',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Wed Feb 6 19:16:42 UTC 2019',
 'python_full_version': '3.7.2',
 'python_version': '3.7',
 'sys_platform': 'linux'}

System environment variables:

  • CI_COMMIT_SHORT_SHA
  • PIPENV_VENV_IN_PROJECT
  • CI_RUNNER_EXECUTABLE_ARCH
  • CI_COMMIT_TITLE
  • CI_JOB_TOKEN
  • CI_BUILD_REF_NAME
  • CI_REGISTRY_PASSWORD
  • CI_RUNNER_TAGS
  • CI_PIPELINE_URL
  • GITLAB_CI_PASSWORD
  • CI_JOB_NAME
  • CI_SERVER_VERSION
  • GITLAB_CI
  • CI_SERVER_REVISION
  • HOSTNAME
  • CI_PROJECT_VISIBILITY
  • CI_DISPOSABLE_ENVIRONMENT
  • CI_COMMIT_SHA
  • CI_COMMIT_MESSAGE
  • CI_BUILD_STAGE
  • CI_PROJECT_URL
  • CI_COMMIT_REF_SLUG
  • CI_SERVER_NAME
  • CI_RUNNER_VERSION
  • CI_BUILD_NAME
  • CI
  • CI_REGISTRY_USER
  • CI_PROJECT_ID
  • CI_PIPELINE_ID
  • CI_JOB_URL
  • CI_COMMIT_DESCRIPTION
  • PWD
  • GITLAB_FEATURES
  • HOME
  • CI_REGISTRY
  • CI_BUILD_TOKEN
  • CI_BUILD_ID
  • GITLAB_USER_NAME
  • CI_COMMIT_BEFORE_SHA
  • CI_PROJECT_PATH_SLUG
  • CI_API_V4_URL
  • GITLAB_USER_EMAIL
  • CI_COMMIT_REF_NAME
  • CI_SERVER_VERSION_PATCH
  • CI_REGISTRY_IMAGE
  • CI_PIPELINE_IID
  • DISTTAG
  • CI_SERVER_TLS_CA_FILE
  • CI_RUNNER_ID
  • FGC
  • CI_SERVER
  • CI_JOB_ID
  • CI_REPOSITORY_URL
  • GITLAB_USER_LOGIN
  • CI_RUNNER_REVISION
  • CI_CONFIG_PATH
  • CI_PROJECT_NAME
  • CI_SERVER_VERSION_MINOR
  • CI_SERVER_VERSION_MAJOR
  • FF_K8S_USE_ENTRYPOINT_OVER_COMMAND
  • CI_NODE_TOTAL
  • SHLVL
  • CI_RUNNER_DESCRIPTION
  • NPM_TOKEN
  • CI_PROJECT_PATH
  • GITLAB_USER_ID
  • CI_BUILD_BEFORE_SHA
  • CI_BUILD_REF
  • PATH
  • CI_PIPELINE_SOURCE
  • CI_PROJECT_NAMESPACE
  • CI_PROJECT_DIR
  • CI_JOB_STAGE
  • CI_BUILD_REF_SLUG
  • _
  • OLDPWD
  • PIP_DISABLE_PIP_VERSION_CHECK
  • PYTHONDONTWRITEBYTECODE
  • PIP_SHIMS_BASE_MODULE
  • PIP_PYTHON_PATH
  • PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

  • PIPENV_VENV_IN_PROJECT: 1

Debug–specific environment variables:

  • PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • PWD: /

@jxltom
Copy link
Contributor

jxltom commented Feb 16, 2019

Could you please show your gitlab CI's configuration to help debugging?

@sedrubal
Copy link
Author

Yes, of course. I'm sorry:

---

variables:
  # removing this doesn't change anything:
  PIPENV_VENV_IN_PROJECT: 1

stages:
  - setup
  - lint
  - check_dependencies
  - test

setup:
  stage: setup
  script:
    # here it fails. It's the very first command, that will be executed:
    - pipenv install
    - ./setup-devel.sh
  tags:
    - docker

# the following is for completeness but should not be related to the issue
django_check:
  stage: lint
  script:
    - pipenv run manage.py check --fail-level=INFO
  tags:
    - docker

translation_check:
  stage: lint
  script:
    - pipenv run translation_check
  tags:
    - docker

prospector:
  stage: lint
  script:
    - prospector --zero-exit
  tags:
    - docker

npm_check_update:
  stage: check_dependencies
  script:
    - yarn global add npm-check-updates
    - ncu --error-level 2
  allow_failure: true
  tags:
    - docker

pipenv_check:
  stage: check_dependencies
  script:
    - PYTHON_VERSION=$(python3 -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")')
    - sed -i "s/python_version =.*/python_version = \"${PYTHON_VERSION}\"/" Pipfile
    - pipenv check
  tags:
    - docker

test:
  stage: test
  script:
    - pipenv run test
  coverage: /^TOTAL\s+\d+\s+\d+\s+(\d+\%)$/
  tags:
    - docker

...

But as I said, I could not reproduce it on gitlab.com...

I've also corrected the pipenv --support section, as it did not contain the env vars from GitLab CI.

@sedrubal
Copy link
Author

I could finally reproduce it 🎉 Inside a project, that uses pipenv, run:

docker run --rm -it -v `pwd`:/srv/:Z fedora bash
# install pipenv and tox
dnf -y install pipenv python3-tox procps-ng
cd /srv/
# ensure that virtual env does not yet exist
rm -rf .venv
export PIPENV_VENV_IN_PROJECT=1
# set the env var CI
export CI=true
# run pipenv without a TTY
setsid sh -c 'tty; ps -jp "$$"; env; pipenv install' < /dev/null > log 2>&1
# see that pipenv is still running
ps aux
# ...but there is no output (if LANG was not set, you can read that pipenv is complaining about)
tail -f log

Now the CPU runs at 100% on one core and pipenv stucks.

It looks like a combination of:

  • python3-tox intalled
  • virtual environment was not yet created
  • environment variable CI is set (it doesn't matter if it is set to 0, 1 or true or whatever)
  • pipenv runs without a TTY
    🤦‍♂️

I hope, you are able to reproduce it now and find the problem...

@techalchemy
Copy link
Member

This may be a bug (I think I've run into this before when combining tox, pytest, etc.

FYI pipenv run manage.py check --fail-level=INFO may not work -- you may need to invoke it via pipenv run python manage.py directly (not sure, but I've seen that in the past)

Alternative approaches include forcibly setting ANSI_COLORS_DISABLED or VISTIR_DISABLE_COLORS (either or both of these could help) -- you could also try PIPENV_COLORBLIND, but I'm not totally sure where things are failing. CI builds may or may not disable color and I'm not sure which parts of the toolchain make that assumption offhand. Let me know if any of this winds up helping

@techalchemy techalchemy added Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided. reported bug labels Feb 17, 2019
@sedrubal
Copy link
Author

FYI pipenv run manage.py check --fail-level=INFO may not work

Thanks for that. In fact it works, when you add a shebang to manage.py and make it executable. But maybe this is not intended 😄

Unfortunately it does not work with any of the variables exported:

The colors are of course disabled, when running pipenv with a TTY. But the bug as described above still exists.

As workaround I'll add an unset CI to my scripts:

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5205b24..b3c08ff 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,6 +2,8 @@

 variables:
   PIPENV_VENV_IN_PROJECT: 1
+  # See https://github.com/pypa/pipenv/issues/3534:
+  CI: ""

 stages:
   - setup

@hernandanielg
Copy link

hernandanielg commented Mar 4, 2019

+  # See https://github.com/pypa/pipenv/issues/3534:
+  CI: ""

This worked like a charm, thanks @sedrubal

I think we should bug an issue to Gitlab

@Peque
Copy link

Peque commented Mar 4, 2019

Crosslinking: #3575

@techalchemy
Copy link
Member

Hrm, that's actually helpful though. Up and down the stack pipenv and https://github.com/sarugaku/vistir (which is what we use for the spinner library) are sensitive to the CI variable which toggles colors on and off

The error logs were even more helpful, I think this was a bug with the old stream wrapper we used to wrap the stderr and stdout streams both in pipenv and in the resolver subprocesses. On the master branch (also in vistir now), we have switched over to a different implementation which provides an uncloseable stream wrapper which I believe was the source of the problem. Interestingly I was not able to reproduce this using Ubuntu-based images but I was successful using fedora based images.

Using the following dockerfile I managed to reproduce the problem, which I then resolved simply by installing a wheel built from the master branch of pipenv -- I simply uncommented the specified line:

FROM fedora as test-container
WORKDIR /srv/
RUN set -ex && dnf -y install pipenv python3-tox procps-ng

COPY Pipfile .
COPY pipenv-2018.11.27.dev0-py3-none-any.whl .

# Uncomment this line and things work
# RUN set -ex && python3 -m pip install --upgrade pipenv-2018.11.27.dev0-py3-none-any.whl tox
ENV CI true
ENV PIPENV_VENV_IN_PROJECT 1

# Install python requirements
RUN set -ex && setsid sh -c 'tty; ps -jp "$$"; env; pipenv install' < /dev/null > log 2>&1
RUN set -ex && ps -aux
RUN set -ex && tail log

My pipfile for this build contains:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
django = "<=2.2.0"

[dev-packages]

[requires]
python_version = "3.6"

With the .dev wheel commented out, the docker container builds forever. If I uncomment that line, the container builds in 32 seconds. I am going to close this out as resolved on master, once we cut the next release you will be able to unset your CI: "" workarounds. Thanks a ton for the debugging help, I don't think we would have tracked this down without it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
reported bug Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided.
Projects
None yet
Development

No branches or pull requests

5 participants