Closed altendky closed 1 year ago
@scott-griffiths, you will likely need to 1) enable actions in the project settings and 2) approve each run since I am a first time contributor here. In the mean time, I'm fixing this up by watching builds from a 'duplicate' PR in my fork at https://github.com/altendky/bitstring/pull/1.
Looks like we've got a bug in the repr()
on Windows where the \
s are neither escaped nor processed to be /
such as with https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.as_posix maybe.
https://github.com/altendky/bitstring/actions/runs/3481674913/jobs/5823070436#step:4:17
ERROR: testRepr (tests.test_bitstream.Split2)
----------------------------------------------------------------------
Traceback (most recent call last):
File "D:\a\bitstring\bitstring\tests\test_bitstream.py", line [19](https://github.com/altendky/bitstring/actions/runs/3481674913/jobs/5823070436#step:4:20)90, in testRepr
f2 = eval(f.__repr__())
File "<string>", line 1, in <module>
File "D:\a\bitstring\bitstring\bitstring.py", line 4250, in __new__
x._initialise(auto, length, offset, **kwargs)
File "D:\a\bitstring\bitstring\bitstring.py", line 1007, in _initialise
self._setfunc[k](self, v, length, offset)
File "D:\a\bitstring\bitstring\bitstring.py", line 1508, in _setfile
with open(pathlib.Path(filename), 'rb') as source:
OSError: [Errno 22] Invalid argument: 'D:\x07\x08itstring\x08itstring\tests\test.m1v'
----------------------------------------------------------------------
Ran 603 tests in 0.5[31](https://github.com/altendky/bitstring/actions/runs/3481674913/jobs/5823070436#step:4:32)s
I included a fix here for the Windows repr()
issue. I admittedly haven't thought through the implications in detail and could certainly extract it to a separate PR.
Now it looks like a flaky situation with PyPy where we sometimes try to remove a file before it's been closed.
https://github.com/altendky/bitstring/actions/runs/3482375222/jobs/5824635734#step:6:13
ERROR: testToFile (tests.test_bitstream.Split2)
----------------------------------------------------------------------
Traceback (most recent call last):
File "D:\a\bitstring\bitstring\tests\test_bitstream.py", line 2414, in testToFile
os.remove(filename)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\a\\bitstring\\bitstring\\tests\\temp_bitstring_unit_testing_file'
@scott-griffiths, there are a couple questions here, but otherwise I think I'm done with a first pass. Might end up with some follow ups, but it's a place to start.
1) Would you like the fix for the Windows repr()
issue extracted to a different PR for separate consideration?
2) How do you want to proceed with the test that's flaky in PyPy?
I would like to have more viable Python interpreter options so I try to encourage PyPy support, at least when projects are close as bitstring seems to be. I'm vaguely guessing there's some issue around the mmap()
creation with the file number being passed to it, but I would have to read up in this area.
Thanks, this looks great. I just tested it out on a different branch as I didn't really know how it worked. Don't worry if some tests are failing - I'm sure I can patch them up, but they don't look like real bugs.
Much appreciated.
Closes https://github.com/scott-griffiths/bitstring/issues/242.
Tests are run across Linux/macOS/Windows, CPython 3.7-3.11, and PyPy 3.7-3.8. First, the wheel and sdist are built and uploaded as workflow artifacts. These can be downloaded from the run summary page. These artifacts are then downloaded, installed, and tested on each platform. The checked out source directory
bitstring/
is deleted to make sure we test the package files themselves. When making a release, these files can be uploaded to PyPI knowing that exactly those files were tested across the whole matrix. Well, I don't test both sdist and wheel separately, but... If you want an auto-upload-on-tag or such addition, we can certainly add that as well. Finally, theAll successful
job only passes if all other jobs have actually succeeded. This works around some GitHub Actions behavior where skipped jobs aren't considered failures but can happen where you as a user might consider them failures. This job can then be added as the single required check in the project branch protection settings instead of having to select every individual job in the matrix and keep the settings updated as the matrix adds and removes elements.