Define what pipeline runs should run tests on which Python versions
Once our pipelines support running tests on multiple Python versions, we should actually decide what versions we want to run tests on.
Definitions:
- Default python version: (currently: 3.7): the version of Python on the dev environments, on which CI runs by default. Should be fairly recent (cough) and match one of the deployment versions
- Deployment versions (currently: 3.7, 3.10): the version of Python we use for deployments.
- Supported versions (currently: undefined): the versions of Python that we support for the whole stack. Must be a superset of the Deployment versions
- Core-supported versions (currently: undefined): the versions of Python that we support for low-level core modules. Must be a superset of the supported versions.
- Tentative versions (currently: none): the versions of Python for which we want to introduce support but currently allow failures for.
Proposal:
Support matrix after introduction of the multiple-version jobs
Label | Versions | Applicable modules |
---|---|---|
Default | 3.10 | |
Deployment | 3.10 | |
Supported | 3.10 | |
User-Facing | 3.8, 3.9, 3.10, 3.11 | swh.scanner, swh.web.client, swh.fuse, swh.deposit |
swh.auth, swh.core, swh.model, swh.scheduler[1] | ||
Tentative | 3.11, 3.12 |
[1] The main problem I see in that is that swh.scheduler currently depends on swh.storage (for iter_origins). I think we can probably drop that though.
What runs when?
- merge request pipeline runs:
- only on default version (or more versions on request, if possible)
- On-push master branch runs:
- on default + deployment versions
- Daily master branch runs:
- Mandatory pass on all supported (or core-supported, if applicable) versions. Report-only run on tentative versions.
- Release runs:
- Mandatory pass on all supported (or core-supported) versions. Report-only run on tentative versions.