Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Do some CI cleanup to make reports clearer and future changes easier#1989

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
Byron merged 3 commits intogitpython-developers:mainfromEliahKagan:ci-cleanup
Jan 4, 2025

Conversation

EliahKagan
Copy link
Member

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.

Sincegitpython-developers#1987, test jobs from `pythonpackage.yml` appear in anunintuitive order, and some show an extra bool matrix variable intheir 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 withoutsetting `continue-on-error` to temporarily work around the problemsobseved ingitpython-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 ingitpython-developers#1814 (by requiring3.9.16-1 as the exact version of the `python39` Cygwin package,along with other supporting changes). We did this to solve aproblem where Python 3.9.18-1, which contained a bug that brokeGitPython CI (and various other software), would be selected.Version 3.9.18-1 was marked back to being a "test" package shortlyafter the bug was reported, and was subsequently removed altogetherfrom the Cygwin repositories. Because the affected package versioneffectively no longer exists, and because this issue is known anda non-"test" version still affected by it is very unlikely to bereleased in the future, this pinning has been decisivelyunnecessary for some time, though still not harmful.This commit undoes the pinning, so that the `python39` package canbe installed at a higher version if one becomes available. Thisserves 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 Ithink it is reasonable to do now.Note that the pinning being undone here only affects thedistinction between different 3.9.* versions. `python39` and`python312` are different Cygwin packages altogether, withcorrespondingly different `python39-*` and `python312-*` associatedpackages; this is not unpinning Python 3.9 in a way that wouldcause Python 3.12 to be selected instead of it.
Copy link
Member

@ByronByron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

That makes sense, thanks a lot!

The initial error seemed spurious so I cancelled the workflow to try again.

@EliahKagan
Copy link
MemberAuthor

Yes,that error is due to#1676.

Byron reacted with thumbs up emoji

@ByronByron merged commita7c7433 intogitpython-developers:mainJan 4, 2025
22 checks passed
@EliahKaganEliahKagan deleted the ci-cleanup branchJanuary 4, 2025 18:02
@EliahKagan
Copy link
MemberAuthor

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 platformsexcept 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 buggitpython-developers/gitdb#115 fixed was 3.13-specific, then it was also needed for that. Theos.path.isabs issue does not apply outside Windows, nor does its generalization in terms of the need to check for how leading-/ and leading-\ paths are treated overall.

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.)

@Byron
Copy link
Member

Thanks for the heads-up.

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.

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.

@EliahKagan
Copy link
MemberAuthor

I've opened#1990 for this.

Byron reacted with thumbs up emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@ByronByronByron approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@EliahKagan@Byron

[8]ページ先頭

©2009-2025 Movatter.jp