Closed twiecki closed 2 years ago
Looking on pypi, the package is uploading with the correct name, so thankfully it's just the test that's failing. So the GITHUB_REF part was copied from the release.yml file. We should be seeing e.g 4.0.0b3
rather than main
. From release.yml:
- name: Check version number match
run: |
echo "GITHUB_REF: ${GITHUB_REF}"
# The GITHUB_REF should be something like "refs/tags/v1.2.3"
# Make sure the package version is the same as the tag
grep -Rq "^Version: ${GITHUB_REF:11}$" pymc.egg-info/PKG-INFO
The syntax :11
means it's taking everything after the 11th char from refs/tags/v1.2.3
. i.e 1.2.3
I'm a bit confused why GITHUB_REF would be different between the release.yml and the nightly.yml files. @michaelosthege might have an idea.
Once we know, I'll open a PR and fix it.
It's different because the release.yml
pipeline is triggered by the creation of the release tag. That's why the GITHUB_REF
is the tag.
But nightly.yml
however is not triggered by the version tag. You'll have to grep the version from __init__.py
instead.
Today, our students using pymc3 received an
ImportError: libmkl_rt.so.1: cannot open shared object file: No such file or directory
when trying to import pymc3. This issue was not present yesterday, so I assume it has something to do with the nightly build? I am in contact with the managers of our environment as well, but they suspect it might be on the pymc3 side
Today, our students using pymc3 received an
ImportError: libmkl_rt.so.1: cannot open shared object file: No such file or directory
when trying to import pymc3. This issue was not present yesterday, so I assume it has something to do with the nightly build? I am in contact with the managers of our environment as well, but they suspect it might be on the pymc3 side
Your problem is most probably unrelated. Your pip list
probably does not list "pymc-nightly".
Try to recreate the environment and if that doesn't work open a new issue
New failure:
Run pip install pymc-nightly==$(grep 'version' pymc/__init__.py | awk '{print $3}' | tr -d '"').dev$(date +"%Y%m%d")
[7](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:7)
grep: pymc/__init__.py: No such file or directory
[8](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:8)
ERROR: Could not find a version that satisfies the requirement pymc-nightly==.dev20220312 (from versions: 4.0.0b2.dev20220302, 4.0.0b2.dev20220303, 4.0.0b2.dev20220304, 4.0.0b3.dev20220308, 4.0.0b3.dev2022030[9](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:9), 4.0.0b3.dev202203[10](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:10), 4.0.0b3.dev202203[11](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:11), 4.0.0b3.dev202203[12](https://github.com/pymc-devs/pymc/runs/5518511673?check_suite_focus=true#step:4:12))
9
ERROR: No matching distribution found for pymc-nightly==.dev20220312
10
WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available.
11
You should consider upgrading via the '/opt/hostedtoolcache/Python/3.9.10/x64/bin/python -m pip install --upgrade pip' command.
12
Error: Process completed with exit code 1.
Hmm the saga continues. This one is a bit confusing. Obviously the file pymc/init.py exists. So it makes me think the github workflow isn't running from the home directory. So I'll open a PR which somehow forces the grep command to execute from ./
Does that seem reasonable or do you thing it might be a different problem? Hopefully this is the last one – it's difficult to fix these workflows when you can't test them
The file doesn't exist because the test-install-job
did not check out the repo code. Compared to the other jobs its missing the checkout action.
CC @theorashid