Skip to content

ci: drop debian-11 (EOL), add debian-13 testing - #2131

Open
twangboy wants to merge 2 commits into
saltstack:developfrom
twangboy:drop_debian11_testing
Open

ci: drop debian-11 (EOL), add debian-13 testing#2131
twangboy wants to merge 2 commits into
saltstack:developfrom
twangboy:drop_debian11_testing

Conversation

@twangboy

@twangboy twangboy commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Debian 11 (bullseye) reached the end of its LTS window on 2026-08-31 (https://www.debian.org/releases/bullseye/). Its security suite is now frozen (the Release file's own Date field is stuck at that exact moment) and packages are becoming unreliable to fetch - this has been repeatedly breaking salt-ci-containers' testing:debian-11 image build, which in turn blocks publication of every other image in the same run (the downstream merge/publish job needs every build matrix entry to succeed, regardless of fail-fast: false).

Salt's own published support policy already excludes this case: "Debian stable, oldstable, and oldoldstable (if it is not EOL) versions." Debian 11 is oldoldstable and is now EOL, so it's outside Salt's own supported list - the "Full" entry in the supported-OS table just hasn't caught up to that yet.

Changes

  • Drop the debian-11 CI job from ci.yml (regenerated via .github/workflows/templates/generate.py)
  • Bump __check_end_of_life_versions's Debian threshold in bootstrap-salt.sh from < 11 to < 12, matching the same hard-block convention already used for other EOL distros (e.g. ALT Linux's < 10 check) and following the precedent of the debian-10 removal (69495e9)
  • Activate debian-13 testing (LINUX_DISTROS/STABLE_DISTROS/ONEDIR_DISTROS in generate.py) so Debian keeps CI coverage. It was already scaffolded in - its git-version blacklist entries (excluding git-3006/git-3007/git-master, allowing git-3008) were already pre-populated, just commented out of the base distro lists - so no further changes were needed there. testing:debian-13's container image already builds successfully in salt-ci-containers, unlike debian-11.

What issues does this PR fix or reference?

Unblocks the ongoing testing:debian-11 breakage in saltstack/salt-ci-containers (PR #141 there is a retry-based mitigation for the underlying mirror flakiness, but this is the real fix - the distro itself is EOL).

Debian 11 (bullseye) reached the end of its LTS window on 2026-08-31
(https://www.debian.org/releases/bullseye/). Its security suite is now
frozen (Release file's own Date field is stuck at that exact moment)
and packages are becoming unreliable to fetch - this has been
repeatedly breaking salt-ci-containers' testing:debian-11 image build,
in turn blocking publication of every other image in the same run
(fail-fast: false doesn't help here since the downstream merge/publish
job still needs every build job to succeed).

Salt's own published support policy already excludes this case:
'Debian stable, oldstable, and oldoldstable (if it is not EOL)
versions.' Debian 11 is oldoldstable and is now EOL, so it falls
outside Salt's own supported list.

Follows the same pattern as the debian-10 removal (69495e9): drop the
CI job and bump __check_end_of_life_versions' Debian threshold from
<11 to <12, matching the same hard-block convention already used for
other EOL distros (e.g. ALT Linux's <10 check).

debian-13 was already scaffolded in generate.py (its git-version
blacklist entries were pre-populated, just commented out of the base
distro lists) - move it from commented to active in LINUX_DISTROS/
STABLE_DISTROS/ONEDIR_DISTROS so Debian keeps CI coverage. Its
existing blacklist entries correctly keep it out of git-3006/git-3007/
git-master while allowing git-3008, so no further changes were
needed there.

testing:debian-13's container image already builds successfully in
salt-ci-containers, unlike debian-11.
debian-11 was already dropped from LINUX_DISTROS/STABLE_DISTROS/
ONEDIR_DISTROS, so these blacklist and display-name entries were
dead weight with no effect on the generated workflow. Confirmed
ci.yml is unchanged after regenerating.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant