🧪 Only run "lowest" & "supported" pip in tox for PR/push @ CI

[webknjaz]

This PR implements "supported" and "lowest" (renamed from "previous") envs in tox. It then integrates both into the CI runs triggered by push and pull_request events.
It drops running the tests against "latest" and "main" envs in regular PRs, keeping them in
the matrix executed on cron.

This improves reproducibility of the CI that will unblock contribution flows.

It additionally fixes reusable workflow conditionals relying on ${{ github.job_workflow_sha }} that are broken within GitHub.

Refs:

• Stability-focused test infra strategy #2140
• Property job_workflow_sha in context github is not available actions/runner#2417 (comment)
• make reference accessible in reusable workflow  actions/toolkit#1264

Contributor checklist

• Included tests for the changes.
• PR title is short, clear, and ready to be included in the user-facing changelog.

Maintainer checklist

• Verified one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[hugovk]

This PR implements "supported" and "minimum" (renamed from "previous") envs in tox. It then integrates both into the CI runs triggered by push and pull_request events.

Looks like "minimum" is actually "lowest" in the code, please could you rename one or the other so the PR title/description matches the code?

[hugovk]

Suggested change

	py{38,39,310,311,312,py3}-pip{supported,lowest,latest,main}-coverage
	pip{supported,lowest,latest,main}-coverage
	pip{supported,lowest,latest,main}
	py{38,39,310,311,312,py3}-pip-{supported,lowest,latest,main}-coverage
	pip-{supported,lowest,latest,main}-coverage
	pip-{supported,lowest,latest,main}

Could we add dashes (and of course elsewhere where referenced) to improve readability?

[webknjaz]

Later. See the other comment.

[hugovk]

What does "supported" actually mean here?

pyproject.toml requires pip >= 22.2, so that maps neatly onto piplowest, but the this lowest is also supported.

Is "pipsupported" the highest version we claim to support?

Like, there's a pip 24.3, but we don't claim to support that (yet)?

If so, would piphighest be clearer, and mirror piplowest better?

(and with dashes for readability)

[webknjaz]

What does "supported" actually mean here?

pyproject.toml requires pip >= 22.2, so that maps neatly onto piplowest, but the this lowest is also supported.

Is "pipsupported" the highest version we claim to support?

Like, there's a pip 24.3, but we don't claim to support that (yet)?

Yes, kind of. I just wanted to have something that is pinned in CI. So after this effort, when a PR fails the CI, it's clear that it's not related to something that said PR changed. I don't want to think too much about this. The immediate goal is to unblock development, and it can be refined later.

If so, would piphighest be clearer, and mirror piplowest better?

Maybe, I was considering it. But in order to avoid spending a lot of time overthinking, I've gone with "supported" as "something we run in CI".

(and with dashes for readability)

I was reminded recently that tox makes dash-separated chunks factors, which might not be desired. I thought about it promptly and decided that it's not worthy of being in the scope of this PR and blocking it. But it could be debated separately, once this is complete. I'm currently blocked on getting #2106 to a working state (plus have some work to do in pypi-publish, which is mostly what's distracting me from this PR).

[hugovk]

Thanks, sounds good. Let's check this again when the other things are in place 👍