Skip to content

build: move the backend images to Debian trixie and Python 3.14 - #9378

Open
DoDiODev wants to merge 2 commits into
apache:mainfrom
DoDiODev:pr/backend-trixie-python314
Open

DoDiODev wants to merge 2 commits into
apache:mainfrom
DoDiODev:pr/backend-trixie-python314

Conversation

@DoDiODev

Copy link
Copy Markdown
Contributor

⚠️ Pre Checklist

Please complete ALL items in this checklist, and remove before submitting

  • I have read through the Contributing Documentation.
  • I have added relevant tests. (N/A — runtime/base image change; existing Python tests run on 3.14, images built and smoke-tested, see below)
  • I have added relevant documentation. (backend/python/DevelopmentSetup.md)
  • I will add labels to the PR, such as pr-type/bug-fix, pr-type/feature-development, etc.
    (I can't set labels myself; suggested: pr-type/refactor, component/devops)

Summary

Two base-image updates that touch the same FROM python:3.11-slim-bookworm
lines, so they come as one PR with two commits:

1. Python 3.11 → 3.14 (build(python): …)

Python 3.11 reaches end of life in October 2027; 3.14 is supported until
October 2030. Since #9352 (Pydantic v2) every locked package has cp314 wheels.

  • backend/Dockerfile, devops/docker/lake-builder/Dockerfile: python:3.14-…
  • python constraint >=3.11,<3.12 → >=3.14,<3.15 in pydevlake, the
    azuredevops, glpi, redmine and zephyr plugins and the test fakeplugin
  • 3× poetry.lock (Poetry 2.5.1, same as the current lock header): only
    python-versions and content-hash change, no package version
  • backend/python/uv.sh: default DEVLAKE_PYTHON_VERSION 3.14
  • .devcontainer/devcontainer.json: Python feature 3.14
  • backend/python/DevelopmentSetup.md: python3.11 → python3.14

3.15 was not chosen: SQLAlchemy 2.0.x (pinned through sqlmodel 0.0.38) has no
cp315 wheels.

2. Debian bookworm → trixie (build(docker): …)

Debian 12 has left regular security support and is only covered by Debian
LTS until June 2028. All remaining bookworm images move to Debian 13:

File Before After
backend/Dockerfile (builder) golang:1.27-bookworm golang:1.27-trixie
backend/Dockerfile (runtime) python:3.14-slim-bookworm python:3.14-slim-trixie
backend/Dockerfile.local (builder + runtime) golang:1.27-bookworm, debian:bookworm-slim golang:1.27-trixie, debian:trixie-slim
devops/docker/lake-builder/Dockerfile python:3.14-slim-bookworm python:3.14-slim-trixie
.devcontainer/Dockerfile devcontainers/go:2-1.27-bookworm devcontainers/go:2-1.27-trixie
  • Dockerfile.local builds without CGO_ENABLED=0, so its binary links
    against the builder's glibc; builder and runtime move together.
    backend/Dockerfile builds with CGO_ENABLED=0 and has no such coupling.
  • trixie changes HOME_MODE to 0700 in /etc/login.defs, so
    useradd -m -d /app would create /app as 0700. A container started
    with a random UID in group 0 (OpenShift) could then no longer enter /app
    (uv: Permission denied). useradd -K HOME_MODE=0755 keeps the bookworm
    behaviour.
  • All apt-get install package names exist unchanged in trixie.
  • config-ui/Dockerfile (node:24-bookworm-slim) is not touched here; its
    builder stage moves to trixie with the Node 26 LTS update.

lake-builder tag: the lake-builder Dockerfile changes, so a new
builder-v* tag is needed before CI picks it up. The Dockerfile already
differs from lake-builder-v0.0.16 (mockery 3.9.0 from #9302, uv pin from
#9364); one new tag would cover all of them. A follow-up PR then bumps the
five container: pins in the workflows.

Does this close any open issues?

N/A

Screenshots

N/A

Other Information

Validation:

  • Python tests (sh ./run_tests.sh, CPython 3.14.10 via uv.sh):
    azuredevops 8 passed/1 skipped, glpi 72/1, redmine 31/1, zephyr 26,
    pydevlake 13. poetry check --lock OK for all three lock files.
  • docker build backend (linux/arm64): OK. In the image: Debian 13,
    Python 3.14.10, uv 0.13.7, git 2.47.3, all four Python plugins built,
    import pydevlake, pydantic, sqlmodel, MySQLdb, psycopg2 OK.
  • docker run -u 123456:0 -e HOME=/tmp …: /app is 755, uv venv OK,
    /app/logs writable, plugin imports OK (fails without the HOME_MODE fix).
  • docker build -f backend/Dockerfile.local backend: OK; Debian 13,
    glibc 2.41, lake starts (no unresolved libraries), git present.
  • docker build --platform linux/amd64 devops/docker/lake-builder: OK;
    Debian 13, Python 3.14.10, Go 1.27.3, uv 0.13.7.
  • docker build .devcontainer: OK; Debian 13, Go 1.27.3,
    python3-dev default-libmysqlclient-dev build-essential libpq-dev installed.
  • CI on my fork with the lake-builder image built from this Dockerfile:
    16/16 jobs green.

DoDiODev and others added 2 commits November 11, 2026 16:53
Raise the Python line in the backend and lake-builder images, the
devcontainer Python feature, the pyproject constraints of pydevlake,
the plugins and the test fakeplugin, the uv.sh default and the
development docs. Python 3.11 reaches end of
life in October 2027; 3.14 is supported until October 2030.

The poetry.lock files only change in their python constraint and
content-hash; no package version changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: DoDiODev <DoDiDev@proton.me>
Debian 12 (bookworm) has left regular security support and is only
covered by Debian LTS until June 2028. Move the remaining bookworm
base images to Debian 13 (trixie): the backend builder and runtime
stages, Dockerfile.local (builder and runtime together, since its binary
is linked against the builder's glibc), the lake-builder image and the
devcontainer.

config-ui is left out; its builder stage moves with the Node 26 update.

trixie's /etc/login.defs sets HOME_MODE 0700, so `useradd -m` would now
create /app as 0700 and a container started with a random UID (as on
OpenShift) could no longer enter it. Pass HOME_MODE=0755 to keep the
bookworm behaviour.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: DoDiODev <DoDiDev@proton.me>
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