Closed gaogaotiantian closed 3 years ago
Adding export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/
in pre-buid-command fixed the issue, but maybe that should be in the project somehow?
I noticed the same today.
In the manylinux image (at least for manylinux2010 which I'm susing), libcrypt.so.2
lives inside /usr/local/lib
, which is listed in the LD_LIBRARY_PATH
.
However, when running the action, a flag -e LD_LIBRARY_PATH
is passed to docker run
, which is probably overriding its value in the image...
From the workflow logs:
/usr/bin/docker run --name e5c3514cf82e21b34543beaae96ab0ceddf34_767251 --label 1e5c35 --workdir /github/workspace --rm -e pythonLocation -e LD_LIBRARY_PATH -e INPUT_PYTHON-VERSIONS -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/PyBaMM/PyBaMM":"/github/workspace" 1e5c35:14cf82e21b34543beaae96ab0ceddf34 "cp36-cp36m cp37-cp37m"
Interestingly, looking at a recent similar workflow (from 19 days ago), the option -e LD_LIBRARY_PATH
isn't passed to docker run
...
Strange... I re-ran tests for Python 3.6, 3.7, and 3.8 with manylinux2010, and -e LD_LIBRARY_PATH
isn't passed in any of them. One difference with the tests is that they are not using the action directly, but building the container in place. Not sure if this would change anything on this end.
The action doesn't control which environment variables (except for arguments) are sent over to the container.
@gaogaotiantian, @tlestang, could you post a link to the action runs that failed?
Hi @RalfG In my case the action is also not ran directly, because I needed to customize the Dockerfile. The way wheels are built is similar to the way the action is tested, i.e. by building the docker image in place. Here's a example failed run: https://github.com/tlestang/PyBaMM/runs/1259747579?check_suite_focus=true
https://github.com/gaogaotiantian/viztracer/runs/1257990060?check_suite_focus=true
This is one of the action that failed. Hope it would be helpful/
Another failed build is here: https://github.com/WeblateOrg/siphashc/runs/1286221254?check_suite_focus=true
I ran into the same issue here:
https://github.com/polm/fugashi/runs/1291199306?check_suite_focus=true
I think it's a change in github. At least on my case, this is the docker run command for a successful run 21 days ago:
/usr/bin/docker run --name e5c35e0346b7e32b841e4ac30a46bcea33215_7e959d --label 1e5c35 --workdir /github/workspace --rm -e PYTHONNOUSERSITE -e pythonLocation -e INPUT_PYTHON-VERSIONS -e INPUT_BUILD-REQUIREMENTS -e INPUT_PIP-WHEEL-ARGS -e INPUT_SYSTEM-PACKAGES -e INPUT_PRE-BUILD-COMMAND -e INPUT_PACKAGE-PATH -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/sqlalchemy/sqlalchemy":"/github/workspace" 1e5c35:e0346b7e32b841e4ac30a46bcea33215 "cp27-cp27m" "setuptools>=44 wheel>=0.34" "" "" "" "-w ./dist --no-use-pep517 -v --no-deps"
this is one that has failed now
/usr/bin/docker run --name e5c35eec274791674458c97be80a5715f072b_c0e630 --label 1e5c35 --workdir /github/workspace --rm -e PYTHONNOUSERSITE -e pythonLocation -e LD_LIBRARY_PATH -e INPUT_PYTHON-VERSIONS -e INPUT_BUILD-REQUIREMENTS -e INPUT_PIP-WHEEL-ARGS -e INPUT_SYSTEM-PACKAGES -e INPUT_PRE-BUILD-COMMAND -e INPUT_PACKAGE-PATH -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/sqlalchemy/sqlalchemy":"/github/workspace" 1e5c35:eec274791674458c97be80a5715f072b "cp27-cp27mu" "setuptools>=44 wheel>=0.34" "" "" "" "-w ./dist --no-use-pep517 -v --no-deps"
They added -e LD_LIBRARY_PATH
It think it's the actions/setup-python@v2
that sets it.
Before running it I have this env PYTHONNOUSERSITE: 1
, after I have PYTHONNOUSERSITE: 1; pythonLocation: /opt/hostedtoolcache/Python/3.8.6/x64; LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.8.6/x64/lib
It think it's the
actions/setup-python@v2
that sets it.Before running it I have this env
PYTHONNOUSERSITE: 1
, after I havePYTHONNOUSERSITE: 1; pythonLocation: /opt/hostedtoolcache/Python/3.8.6/x64; LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.8.6/x64/lib
Indeed it seems to be this issue https://github.com/actions/setup-python/issues/131
@RalfG I think that the script that runs could be updated so that the correct LD_LIBRARY_PATH
is appended to the one provided by the user.
A workaround has been implemented in #28, now available in RalfG/python-wheels-manylinux-build@v0.3.2
My script works for a long time and suddenly broke recently. Not sure if it's a docker issue or the library env setup.
The problem is similar to https://github.com/pypa/manylinux/issues/357