Do some CI cleanup to make reports clearer and future changes easier #1989
Conversation
Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an unintuitive order, and some show an extra bool matrix variable in their names while others don't (this corresponds to `experimental`, which was always set to some value, but was set in different ways). This fixes that by: - Listing all tested versions, rather than introducing some in an `include` key. (The `include:`-introduced jobs didn't distinguish between originally-present matrix variables and those that are introduced based on the values of the original ones.) - Replacing `os` with `os-type`, which has only the first part of the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver` to each matrix job, defaulting it to `latest`, but using `22.04` for Python 3.7 on Ubuntu. This should also naturally extend to adding 3.13, with or without setting `continue-on-error` to temporarily work around the problems obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.
This goes a bit further in the direction of the preceding commit, making CI reports/logs a bit more intuitive.
We pinned Python 3.9.16 on Cygwin CI in gitpython-developers#1814 (by requiring 3.9.16-1 as the exact version of the `python39` Cygwin package, along with other supporting changes). We did this to solve a problem where Python 3.9.18-1, which contained a bug that broke GitPython CI (and various other software), would be selected. Version 3.9.18-1 was marked back to being a "test" package shortly after the bug was reported, and was subsequently removed altogether from the Cygwin repositories. Because the affected package version effectively no longer exists, and because this issue is known and a non-"test" version still affected by it is very unlikely to be released in the future, this pinning has been decisively unnecessary for some time, though still not harmful. This commit undoes the pinning, so that the `python39` package can be installed at a higher version if one becomes available. This serves two purposes. - There is work under way in porting Python 3.12 to Cygwin. To test this with GitPython (either while it is in development or later), it will be useful to turn the Cygwin test job into a matrix job definition, generating two jobs, one for Python 3.9 and one for Python 3.12. Since 3.12 will probably not benefit from pinning, dropping pinning simplifies this. - If the port of Python 3.12 to Cygwin is successful, it might lead to a solution to the but that currently keeps 3.9.18 from being made available for Cygwin. In that case, another 3.9.18-* Cygwin package would be released, which we would want to use. Although this is uncertain, the change is a simplification, so I think it is reasonable to do now. Note that the pinning being undone here only affects the distinction between different 3.9.* versions. `python39` and `python312` are different Cygwin packages altogether, with correspondingly different `python39-*` and `python312-*` associated packages; this is not unpinning Python 3.9 in a way that would cause Python 3.12 to be selected instead of it.
|
Yes, that error is due to #1676. |
|
Another part of #1955 that could be brought in now is that GitPython is expected to, and seems to, completely work on Python 3.13 on all platforms except Windows--where it probably mostly works, but does not fully work. To fully support running, building, and testing GitPython with Python 3.13 fully non-Windows systems, either only #1954 was needed, or if the bug gitpython-developers/gitdb#115 fixed was 3.13-specific, then it was also needed for that. The So Python 3.13 could be tested now on non-Windows systems. I don't know if you want that, or if you prefer to wait until it works on Windows and having that come in with #1955. (The special-casing, if it is done, would not be cumbersome. One way to do it would be the same way we exclude Python 3.7 from being tested on macOS.) |
|
Thanks for the heads-up.
Since you'd be the one driving this I would leave it up to you to decide if it's worth having conditional testing to start testing earlier. To me it seems beneficial to have it as well. |
|
I've opened #1990 for this. |
Neither #1955 nor #1988 is ready yet, but both include commits that clean up CI and that I think are already valuable. Some of the changes make GitHub Actions checks easier to read (8a05390, 41377d5), while another removes some complexity that is no longer needed (73ddb22). So I cherry-picked those commits onto a new feature branch, which this PR proposes merging. If this is merged, I'll rebase those other PRs to drop the corresponding commits from them. Details on the changes are in the commit messages.