CI: Run tests in Cygwin for Cygwin CI #78

DWesl · 2022-06-10T17:58:54Z

The current version installs the Cygwin base packages (but not any python versions), then runs the rest of the steps using the previously-installed Windows-native python. This should run the tests in a Cygwin python.

DWesl · 2022-06-21T01:05:29Z

I think all the Cygwin failures are related to GitPython deciding to turn all paths into Windows-format (instead of Cygwin-format) on Cygwin (causing the paths to be interpreted as relative rather than absolute), so this should probably wait until gitpython-developers/GitPython#1455 goes in so the tests have a chance of passing.

FFY00

Hi @DWesl, thank you so much for looking into this! It is highly appreciated.

The PR looks great, I just want to wait for a new GitPython release before merging so that we can be sure that is why the tests are currently failing.

FFY00 · 2022-09-28T18:38:09Z

I think it's gonna be a while, so I am gonna rebase and merge this PR.

Signed-off-by: Filipe Laíns <lains@riseup.net>

Hopefully this lets test setup complete. Signed-off-by: Filipe Laíns <lains@riseup.net>

Signed-off-by: Filipe Laíns <lains@riseup.net>

tests/test_wheel.py

There's a bunch of failures due to "git: not in repository" errors, so let's try to stay in a repository. Signed-off-by: Filipe Laíns <lains@riseup.net>

DWesl · 2022-09-28T19:25:22Z

I think it's gonna be a while, so I am gonna rebase and merge this PR.

Should we install GitPython from the repository rather than from PyPI so the fix is included? I think the tests still fail with the released version.

Signed-off-by: Filipe Laíns <lains@riseup.net>

FFY00 · 2022-09-28T21:47:40Z

We are now installing from the repo but there are still errors, I don't know what's going on. @DWesl can you try running the tests with nox on a Cygwin environment?

There are a few other ways these changes could be made Tweak the regex to accept different file extensions Combine the Windows and Cygwin paths for adding .dll.a files

dnicolodi · 2022-11-12T15:07:14Z

@DWesl The current way to generate wheel tags from extension filenames is doomed. I think the sane approach is the one in #202. It should already work with Cygwin but IIUC our CI setup is incomplete. Do you mind if I cherry pick the CI extension commits from this PR into that one?

DWesl · 2022-11-12T19:13:08Z

We are now installing from the repo but there are still errors, I don't know what's going on. @DWesl can you try running the tests with nox on a Cygwin environment?

The most recent commit passes locally, except for what I suspect are local network errors.

@DWesl The current way to generate wheel tags from extension filenames is doomed. I think the sane approach is the one in #202. It should already work with Cygwin but IIUC our CI setup is incomplete. Do you mind if I cherry pick the CI extension commits from this PR into that one?

You are welcome to try it.

dnicolodi · 2022-11-12T23:25:24Z

CI is not very happy. There seems to be something wrong with git in Cygwin.

I hope this allows git to find the repository and the complain because it isn't trusted

dnicolodi · 2022-11-13T00:10:49Z

.github/workflows/tests-cygwin.yml

@@ -56,7 +56,6 @@ jobs:
          TMP: "/tmp"
          TEMP: "/tmp"
        run: |
-          cd "${GITHUB_WORKSPACE}"


The code that fails is this

meson-python/tests/conftest.py

Lines 33 to 51 in ef67e0e

def in_git_repo_context(path=os.path.curdir):

path = pathlib.Path(path)

assert path.absolute().relative_to(package_dir)

shutil.rmtree(path / '.git', ignore_errors=True)

try:

handler = git.Git(path)

handler.init()

handler.config('commit.gpgsign', 'false')

handler.config('user.name', 'Example')

handler.config('user.email', 'example@example.com')

handler.add('*')

handler.commit('--allow-empty-message', '-m', '')

handler.tag('-a', '-m', '', '1.0.0')

yield

finally:

try:

shutil.rmtree(path / '.git')

except PermissionError:

pass

which is called for example here

meson-python/tests/conftest.py

Line 96 in ef67e0e

with cd_package(package), in_git_repo_context():

It should not depend on CWD of the tests runner. Why it fails although is not very clear.

I was going to say "GitPython hasn't done a release since they merged the changes to get it working on Cygwin", but apparently that's only true on GitHub; PyPI had two releases a month ago.

actions/checkout is done with Windows git, not Cygwin, so there would be (different) errors operating on the meson-python repository, but the errors are apparently from a brand-new repository, so that's not it either.

My next guess would be fork() failure since CI runs into that a decent bit, but this project doesn't have many dependencies, nor does it have many C extension modules, and also I think I've found the actual stdout and stderr in the logs, which show a different message.

There's no reasons coming to mind for why rm -rf .git; git init; git config gpgsign false would fail, especially with that error

Indeed. By the way @DWesl , do you know if there is a n easy way to cache the cygwin installation done by the cygwin/cygwin-install-action? Debugging this on the CI having to wait for Cygwin to install at each run is a bit tedious. On a branch I setup caching for the Python dependencies, cutting down the pip install time considerably, but installing Cygwin still takes anything between one minute and a half and three minutes.

The fix for the git issue is this:

meson-python/.github/workflows/tests.yml

Lines 91 to 98 in 68e1d39

- name: Fix git dubious ownership

# This addresses the "fatal: detected dubious ownership in

# repository" and "fatal: not in a git directory" errors

# encountered when trying to run Cygwin git in a directory not

# owned by the current user. This happens when the tests run

# Cygwin git in a directory outside the Cygwin filesystem.

run: git config --global --add safe.directory '*'

shell: C:\cygwin\bin\env.exe CYGWIN_NOWINPATH=1 CHERE_INVOKING=1 C:\cygwin\bin\bash.exe -leo pipefail -o igncr {0}

So it's the second issue, but git for some reason decided to have two error messages for that. Lovely

Won't work until the CI run succeeds, but should speed things up after that.

Git's failing to configure GnuPG, so hopefully that goes away if there's an actual GnuPG installation.

dnicolodi · 2022-11-13T14:41:11Z

.github/workflows/tests-cygwin.yml

+        with:
+          path: 'C:\cygwin'
+          key: ${{ runner.os }}-cygwin-python-3${{ matrix.python-minor }}-${{ hashfiles('pyproject.toml') }}
+


This is not enough. With this the installation path is populated but the installation will be run anyway. I don't think this saves any time. Anyhow, I can live with the CI job taking a couple of minutes.

The installation will be run, but that cache includes the list of installed packages; the install step will only download and extract packages if there are new versions (which means I should expire the cache at least once a month). I would very much prefer to run the installer to be sure the dlls get rebased properly (which means I need to run rebase-trigger full so it knows to do that).

You're probably going to have more runins with the length of the CI job; most of the ones I've built take half an hour. Should I take this back out again?

I don't think we will be merging this PR either way. The work in #202 supersedes all of it. I just have one funny test error on Cygwin to track down: https://github.com/mesonbuild/meson-python/actions/runs/3456021871/jobs/5768534392 We setup two virtual environments as part of the tests, for some reason the second time we do it, it fails. The annoying thing is that it fails with a backtrace that does not match my copy of the CPython 3.9.15 source code and I haven't been able to locate the Cygwin Python sources

If you've got a Cygwin install, run setup-x86_64.exe again and check the Src? tick box; you may also want to install the cygport package to simplify the build process (cygport python39.cygport download prep compile test install package if you want to do a local install, using the Cygwin source package mentioned above and a local download repository)

You may also want to check the CPython 3.9.10 source, since that's what's getting installed in the failing CI job

I don't have any Windows machine were to install Cygwin. I was hoping that a git repository with the sources exists somewhere. With your indications above I found it, https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python39.git but it seems the sources are maintained as a set of patches... This is so '90ies... 😄

Accordingly to https://cygwin.com/cgi-bin2/package-grep.cgi there is no Cygwin package that installs something in/usr/share/python-wheels/ so I am not sure I understand how the patch you linked is even supposed to work.

@DWesl can you please check the content of /usr/share/python-wheels/ on your Cygwin system?

I have a few hundred wheels in there, because I often create my own packages and make sure my packages install wheels there so I don't have to sit waiting for scipy to build every time I want to test something with tox. I think it worked fine before I started doing that, but I haven't checked.

Also, what does it happen if you do something like python -m venv $(mktemp -d)?

Works the same as the other one, once I found the temporary environment.

It looks like the function assumes there is some file for the package, but only looks for architecture independent packages; is it perhaps finding only sdists and architecture-dependent wheels?

Uh? Why do you have wheel files in there? Also, wheel files are only a distribution bundle, they need to be unpacked to be used, so if you install a wheel package you don't have any wheel file at the end, except in a cache, maybe. However, /usr/share/python-wheels/ is not the default path of the pip cache.

When venv creates a new virtual environment it optionally populates it with the setuptools and pip packages. Because pip does not exist yet in the virtual environment, the ensurepip module is used for doing it. Customarily, the Python distribution comes with two wheel files for setuptools and pip bundled with it and these are unpacked by ensurepip into the virtual environment. Cygwin decided to patch ensurepip to look for the wheel it needs in /usr/share/python-wheels/ but it does not place any wheel there. How is this supposed to work? Who should place the wheels there?

Now that we understood the issue, I'm patching it in the CI setup. But Python as distribute by Cygwin is broken.

The fix

meson-python/.github/workflows/tests.yml

Lines 117 to 128 in f0ce0f5

- name: Install

# Cygwin patches Python's ensurepip module to look for the

# wheels needed to initialize a new virtual environment in

# /usr/share/python-wheels/ but nothing in Cygwin actually

# puts the setuptools and pip wheels there. Fix this.

run: |

mkdir /usr/share/python-wheels/

pushd /usr/share/python-wheels/

python -m pip --disable-pip-version-check download setuptools pip

popd

python -m pip --disable-pip-version-check install .[test]

shell: C:\cygwin\bin\env.exe CYGWIN_NOWINPATH=1 CHERE_INVOKING=1 C:\cygwin\bin\bash.exe -leo pipefail -o igncr {0}

Now the tests succeed on Cygwin too!

DWesl · 2022-11-16T16:12:52Z

Superseded by #202

DWesl mentioned this pull request Jun 21, 2022

CI: Run tests in Cygwin for Cygwin CI DWesl/meson-python#1

Closed

FFY00 approved these changes Jun 21, 2022

View reviewed changes

DWesl added 6 commits September 28, 2022 19:38

CI: Run tests in Cygwin for Cygwin CI

e56b8c1

Signed-off-by: Filipe Laíns <lains@riseup.net>

CI: Include /usr/local/bin in PATH.

dc1a5c2

Signed-off-by: Filipe Laíns <lains@riseup.net>

CI: Add cmake et al. to Cygwin install.

e80d0fd

Hopefully this lets test setup complete. Signed-off-by: Filipe Laíns <lains@riseup.net>

CI: Add gcc to Cygwin run

69b5f9e

Signed-off-by: Filipe Laíns <lains@riseup.net>

CI: Add g++ compiler to Cygwin CI run.

28ea075

Signed-off-by: Filipe Laíns <lains@riseup.net>

CI: Add git to Cygwin CI run.

640c462

Signed-off-by: Filipe Laíns <lains@riseup.net>

FFY00 force-pushed the patch-1 branch from 905a05a to a7f1bf3 Compare September 28, 2022 18:41

rgommers added the CI Continuous Integration label Sep 28, 2022

rgommers reviewed Sep 28, 2022

View reviewed changes

tests/test_wheel.py Outdated Show resolved Hide resolved

CI: Try to ensure Cygwin tests start in right place

9cc6895

There's a bunch of failures due to "git: not in repository" errors, so let's try to stay in a repository. Signed-off-by: Filipe Laíns <lains@riseup.net>

FFY00 force-pushed the patch-1 branch from a7f1bf3 to 9cc6895 Compare September 28, 2022 18:51

TST: add support for cygwin

b39a58b

Signed-off-by: Filipe Laíns <lains@riseup.net>

FFY00 force-pushed the patch-1 branch from 63a5f14 to b39a58b Compare September 28, 2022 20:05

TST: install GitPython from repo on Cygwin

fdb2d63

Signed-off-by: Filipe Laíns <lains@riseup.net>

FFY00 force-pushed the patch-1 branch from 2a06578 to fdb2d63 Compare September 28, 2022 20:36

ENH: Get tests passing on Cygwin.

b0f12d1

There are a few other ways these changes could be made Tweak the regex to accept different file extensions Combine the Windows and Cygwin paths for adding .dll.a files

Merge branch 'main' into patch-1

34c6aa5

CI: Don't change directory.

ec1aa14

I hope this allows git to find the repository and the complain because it isn't trusted

dnicolodi reviewed Nov 13, 2022

View reviewed changes

DWesl added 2 commits November 13, 2022 06:34

CI: Try to cache the Cygwin installation.

cddc959

Won't work until the CI run succeeds, but should speed things up after that.

CI: Install GnuPG to see if that fixes git failure.

c6761f6

Git's failing to configure GnuPG, so hopefully that goes away if there's an actual GnuPG installation.

CI: Install meson to ensure all dependencies are present.

c6566c7

dnicolodi reviewed Nov 13, 2022

View reviewed changes

DWesl and others added 3 commits November 13, 2022 12:19

CI: Tell Cygwin git about the repository.

7d09e52

CI: Download wheels for ensurepip

7e866c4

CI: Install pkg-config for tests.

e27a22b

DWesl closed this Nov 16, 2022

	def in_git_repo_context(path=os.path.curdir):
	path = pathlib.Path(path)
	assert path.absolute().relative_to(package_dir)
	shutil.rmtree(path / '.git', ignore_errors=True)
	try:
	handler = git.Git(path)
	handler.init()
	handler.config('commit.gpgsign', 'false')
	handler.config('user.name', 'Example')
	handler.config('user.email', 'example@example.com')
	handler.add('*')
	handler.commit('--allow-empty-message', '-m', '')
	handler.tag('-a', '-m', '', '1.0.0')
	yield
	finally:
	try:
	shutil.rmtree(path / '.git')
	except PermissionError:
	pass

	- name: Fix git dubious ownership
	# This addresses the "fatal: detected dubious ownership in
	# repository" and "fatal: not in a git directory" errors
	# encountered when trying to run Cygwin git in a directory not
	# owned by the current user. This happens when the tests run
	# Cygwin git in a directory outside the Cygwin filesystem.
	run: git config --global --add safe.directory '*'
	shell: C:\cygwin\bin\env.exe CYGWIN_NOWINPATH=1 CHERE_INVOKING=1 C:\cygwin\bin\bash.exe -leo pipefail -o igncr {0}

	- name: Install
	# Cygwin patches Python's ensurepip module to look for the
	# wheels needed to initialize a new virtual environment in
	# /usr/share/python-wheels/ but nothing in Cygwin actually
	# puts the setuptools and pip wheels there. Fix this.
	run: \|
	mkdir /usr/share/python-wheels/
	pushd /usr/share/python-wheels/
	python -m pip --disable-pip-version-check download setuptools pip
	popd
	python -m pip --disable-pip-version-check install .[test]
	shell: C:\cygwin\bin\env.exe CYGWIN_NOWINPATH=1 CHERE_INVOKING=1 C:\cygwin\bin\bash.exe -leo pipefail -o igncr {0}

CI: Run tests in Cygwin for Cygwin CI #78

CI: Run tests in Cygwin for Cygwin CI #78

Uh oh!

Conversation

DWesl commented Jun 10, 2022

Uh oh!

DWesl commented Jun 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FFY00 left a comment

Choose a reason for hiding this comment

Uh oh!

FFY00 commented Sep 28, 2022

Uh oh!

Uh oh!

DWesl commented Sep 28, 2022

Uh oh!

FFY00 commented Sep 28, 2022

Uh oh!

dnicolodi commented Nov 12, 2022

Uh oh!

DWesl commented Nov 12, 2022

Uh oh!

dnicolodi commented Nov 12, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DWesl Nov 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DWesl Nov 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DWesl commented Nov 16, 2022

Uh oh!

Uh oh!

DWesl commented Jun 21, 2022 •

edited

Loading

DWesl Nov 13, 2022 •

edited

Loading

DWesl Nov 13, 2022 •

edited

Loading