CHORE: gate PR validation on supported Django, run EOL versions on nightly - #566
Merged
Gaurav Sharma (bewithgaurav) merged 1 commit intoAug 7, 2026
Merged
Conversation
…ghtly Split the PR-validation matrix into a Core tier (Django 5.2 and 6.0, the versions still supported upstream) that runs on every PR/CI build, and a Legacy tier (3.2, 4.0, 4.1, 4.2, 5.0, 5.1) gated to the nightly schedule and manual queues. Per-leg steps move into shared templates so the Core and Legacy jobs do not duplicate them. setup.py and tox.ini are untouched: support for the older versions is not dropped, only moved off the per-PR gate. The full matrix still runs nightly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot started reviewing on behalf of
Gaurav Sharma (bewithgaurav)
August 7, 2026 07:52
View session
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Jahnvi Thakkar (jahnvi480)
approved these changes
Aug 7, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refactors the Azure DevOps PR-validation pipeline to reduce per-PR CI load by splitting the test matrix into “Core” (supported upstream Django versions) that runs on every PR/CI build, and “Legacy” (EOL Django versions) that runs only on scheduled nightly builds or manual queues. It also centralizes per-leg build/test steps into shared YAML templates to avoid duplication across jobs.
Changes:
- Split Windows/Linux jobs into Core (always) and Legacy (schedule/manual only) tiers via job-level
condition. - Extract per-leg Windows and Linux build/test steps into
azure-pipelines-steps-*.ymltemplates referenced by both tiers. - Preserve full Django version coverage by running the full matrix on nightly/manual runs.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| azure-pipelines.yml | Splits the CI matrix into Core/Legacy jobs and wires both to shared step templates. |
| azure-pipelines-steps-windows.yml | New shared Windows template containing CredScan, Python selection, SQL Server/ODBC setup, and tox execution. |
| azure-pipelines-steps-linux.yml | New shared Linux template containing Docker SQL Server startup, ODBC/tools install, tox execution, and result publishing. |
Suppressed comments (3)
azure-pipelines.yml:227
- This CI matrix entry runs
py311-django41, but tox's declared envlist fordjango41only includes {py38,py39,py310} (tox.ini:5). Consider removing this row (or updating tox.ini to declare/support it) so CI reflects the intended compatibility matrix.
Python3.11 - Django 4.1:
python.version: '3.11'
tox.env: 'py311-django41'
azure-pipelines.yml:239
- This CI matrix entry runs
py311-django40, but tox's declared envlist fordjango40only includes {py38,py39,py310} (tox.ini:4). Aligning Linux nightly legs with tox.ini will make the CI matrix easier to reason about and avoid unexpected failures.
Python3.11 - Django 4.0:
python.version: '3.11'
tox.env: 'py311-django40'
azure-pipelines.yml:251
- This CI matrix entry runs
py311-django32, but tox's declared envlist fordjango32only includes {py36,py37,py38,py39} (tox.ini:3). Removing this row keeps nightly CI aligned with the declared supported environments.
Python3.11 - Django 3.2:
python.version: '3.11'
tox.env: 'py311-django32'
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Splits the PR-validation matrix into two tiers:
Windows_Core/Linux_Core) runs on every PR and CI build. It covers the Django versions still supported upstream today: 5.2 (LTS) and 6.0.Windows_Legacy/Linux_Legacy) covers the end of life versions 3.2, 4.0, 4.1, 4.2, 5.0 and 5.1. These run only on the nightly schedule (or a manual queue), gated withcondition: or(eq(variables['Build.Reason'], 'Schedule'), eq(variables['Build.Reason'], 'Manual')).The per-leg build/test steps move into
azure-pipelines-steps-windows.ymlandazure-pipelines-steps-linux.ymlso the Core and Legacy jobs share one step definition instead of duplicating ~150 lines of setup shell.Why
The matrix had grown to 29 legs per OS (58 total) on every PR, and more than half of that is Django versions that are end of life upstream. Gating PRs on the currently supported set keeps the fast feedback lean while the nightly still exercises the full history.
Support status as of today (per endoflife.date):
Coverage is not dropped
This changes when the old versions run, not whether.
setup.pyandtox.iniare untouched, so we still declare and test Django 3.2 through 6.0. The full matrix runs nightly (always: true) and on manual queue.Legs per run
Django 6.1 is not on
devyet; it joins the Core tier via #564, taking Core to 10 legs per OS (20 total).