Closed lohedges closed 1 year ago
A quick guess is that the Windows runner has run out of disk space during the build, and so either the tar.bz2 file wasn't fully written after the build, or it couldn't be unpacked to run the test? Maybe after a build we should run a make clean or similar to free up disk space?
Possibly. Subsequent stages in the CI did run, though, i.e. the creation and uploading of failed build artifacts. I would have thought that this would have failed too if the disk space had been exhausted. Perhaps there is a limit for the actual build process itself?
Would we clean by just removing the Sire build
directory after the installation? I guess the issue here is that we might want to examine those files if it fails, i.e. we'd want them to be included in the artifact that gets uploaded.
The issue does look weird. While we could spend time looking into this, I don't think fixing this would add much value? Is anyone using the Python 3.7 Windows binaries?
If not, and especially given that we will drop 3.7 support when we move to 3.10, my vote is to drop Windows 3.7 now from the CI/CD.
Yes, it doesn't look like anyone is using py37 on any platform at present, so it might just be worth deprecating it to avoid annoying end-of-life maintenance issues over the next six months or so. Anyone who really needs it can get it touch, at which point we can try to figure out specific issues if it's not too much of a challenge.
Yes - let's deprecate 3.7 across all platforms. This will save the CI cycles on GH Actions and will push us to move to 3.10 once our dependencies are ready.
Okay, this is now happening for all Windows builds with no changes to the CI. We'll need to address this as I need a working Windows conda package for Cresset to play with.
I think this is the key error line:
conda_package_handling.exceptions.InvalidArchiveError: Error with archive D:\a\Sire\Sire\build\win-64\sire-2023.0.1-py37h82bb817_4.tar.bz2. You probably need to delete and re-download or re-create this file. Message from libarchive was:
For some reason, conda build isn't able to create a non-corrupt sire tbz2 package after the compile. This implies that the tar process exited badly but this error wasn't caught? Did the CI give you the broken outputs to download and inspect on your computer?
It may be worth checking whether or not the sire tbz2 file is corrupt, and also how? (is it an empty file, so nothing was compressed, or does it end half way through?).
My guess is that the tar process used to create it either ran out of memory or disk space and this wasn't caught. A workaround could be us deleting the contents of the build
directory after sire has installed? This should free up plenty of space.
Good plan. I'll update the build scripts to remove the build
directory only if the install succeeds. It's just strange that this was originally py37 specific, but is now occurring for all variants. (All variants are running on the same Windows image.) It makes me think that something in the conda-build chain has changed, with py37 being updated/affected earlier.
Will see how we get on.
Yes, this has fixed the issue.
The CI gives the following error in the log during the testing stage of the
conda build
process:The same thing happened during a previous build attempt, although the error message was slightly different: