Dependabot і Python 3.9: як не втратити dependency updates після 23 червня

Зачіпка

GitHub дав конкретну дату: 23 червня 2026 Dependabot перестане підтримувати Python 3.9. Якщо в репозиторії досі зав’язаний Python 3.9, автоматичні PR-и з оновленнями залежностей можуть просто перестати приходити.

Це не той тип міграції, який добре лишати “на колись”. Тут ризик неприємний саме тому, що він тихий: нічого не падає у production одразу, але supply-chain hygiene поступово слабшає.

Проблема / Контекст

19 травня 2026 GitHub попередив про майбутнє припинення підтримки Python 3.9 у Dependabot. Дедлайн - 23 червня 2026. Після нього репозиторії, які лишаються на Python 3.9 у контурі Dependabot, ризикують не отримувати автоматичні dependency update PR-и.

Окремо важливо: Python 3.9 вже має статус EOL. За офіційним Python Developer Guide ця лінія завершила підтримку 31 жовтня 2025. Тобто це не попередній дзвіночок про майбутній legacy, а нагадування, що automation навколо старого runtime теж поступово від’їжджає.

Для Dependabot Python-екосистема - це не лише один файл requirements.txt. У GitHub Docs згадані pip, pip-compile, pyproject.toml за PEP 621 та інші звичні manifests. Тому аудит має шукати не “де у нас є Python”, а “де GitHub реально намагається оновлювати Python-залежності”.

Чому це важливо

Dependabot часто стоїть у репозиторії як фоновий охоронець. Він не замінює нормальну security-програму, але регулярно піднімає дрібні оновлення, CVE-патчі й сумісні версії пакетів. Коли цей сигнал зникає, команда може помітити проблему тільки через місяць або після ручного аудиту.

Типові наслідки:

• security fix у пакеті вийшов, але PR не відкрився;
• lockfile повільно старіє;
• CI лишається зеленим, хоча automation уже неповний;
• команда думає, що “немає оновлень”, хоча насправді Dependabot не зміг їх обробити;
• міграція runtime переноситься, бо не має видимого owner-а.

Найбільше це зачіпає backend, data, internal tools, Django/FastAPI-сервіси, automation scripts і monorepo, де Python не завжди головний продукт. У таких репозиторіях старий runtime легко ховається у CI matrix, Dockerfile або devcontainer, а не тільки в application code.

Ілюстрація: де ховається Python 3.9

Уяви репозиторій як невеликий склад. На вході висить табличка “ми вже на Python 3.12”, бо production image справді оновили. Але на дальній полиці лежить старий tox.ini, у CI matrix досі є 3.9, devcontainer бере python:3.9, а onboarding docs радять встановити pyenv install 3.9.19.

Dependabot може спіткнутися не там, де ти очікуєш. Тому перевірка має пройти через усі місця, де runtime впливає на dependency automation.

Як це зробити

1. Знайди репозиторії, де Dependabot працює з Python

Почни з .github/dependabot.yml. Для одного репозиторію достатньо відкрити файл і подивитися на updates. Для організації краще зібрати список централізовано через GitHub API або внутрішній script.

Шукай такі ecosystems:

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

Також перевір репозиторії, де Python-залежності лежать не в корені. У monorepo directory може вказувати на services/api, tools/reports, infra/scripts або іншу вкладену папку.

Результат першого кроку має бути простим списком:

• repository;
• package ecosystem;
• directory;
• manifests, які там є;
• owner команди або сервісу;
• коли Dependabot востаннє відкривав PR.

2. Перевір усі місця, де зафіксовано Python 3.9

Після цього не обмежуйся application manifests. Python 3.9 часто живе в обслуговуючих файлах:

.github/workflows/*.yml
Dockerfile
docker-compose.yml
.devcontainer/devcontainer.json
runtime.txt
.python-version
tox.ini
noxfile.py
pyproject.toml
README.md
docs/onboarding.md

Особливо уважно дивись на CI matrix:

strategy:
  matrix:
    python-version: ["3.9", "3.10", "3.11"]

Якщо Python 3.9 потрібен тільки для backward compatibility tests, це окрема розмова. Але якщо це основна або єдина версія для tests, lint, packaging чи lockfile generation, її треба підняти.

3. Вибери цільову версію

Не оновлюй “кудись”. Вибери підтримувану лінію і запиши це в репозиторії. Для більшості команд нормальний мінімум - перейти хоча б на Python 3.10 або 3.11, а краще на актуальну підтримувану лінію, якщо залежності дозволяють.

Практичний підхід:

• якщо сервіс уже проходить tests на 3.10 або 3.11, прибери 3.9 з матриці і зроби нову версію default;
• якщо tests падають на новішій версії, відділи package compatibility від runtime config;
• якщо пакет не підтримує новіший Python, створюй issue з owner-ом і deadline, а не ховай проблему в CI;
• якщо старий runtime потрібен клієнтам, не прив’язуй до нього Dependabot automation для всього репозиторію.

Головне - не змішувати “ми ще підтримуємо старих користувачів” і “наша внутрішня dependency automation має працювати на старому runtime”. Це різні рішення.

4. Онови CI, base images і локальне середовище

Мінімальний PR зазвичай торкається кількох шарів.

У GitHub Actions:

- uses: actions/setup-python@v5
  with:
    python-version: "3.12"

У Dockerfile:

FROM python:3.12-slim

У devcontainer:

{
  "image": "mcr.microsoft.com/devcontainers/python:3.12"
}

У docs для onboarding прибери старі команди встановлення Python 3.9. Інакше нові люди в команді через місяць знову принесуть старий runtime у локальні lockfile-и або scripts.

5. Прогони тести як міграцію, а не як формальність

Після runtime bump перевір не тільки unit tests. Для Python-проєктів часто важливі такі кроки:

• створення чистого virtualenv;
• pip install -r requirements.txt;
• генерація lockfile через pip-compile, якщо він використовується;
• import smoke test для основного застосунку;
• Django/FastAPI старт без міграційної паніки;
• job, який Dependabot зазвичай тригерить після свого PR.

Якщо залежності впали на build step, це ще не означає, що вся міграція складна. Часто треба оновити один пакет, прибрати старий constraint або перейти на wheel, який підтримує новішу версію Python.

6. Перевір сам Dependabot

Фінальний критерій - не “CI зелений”, а “Dependabot знову може створити update PR”.

Перевір:

• у repository insights або security/dependency graph немає свіжих помилок Dependabot;
• останній Dependabot run не падає на Python setup;
• manifests визначаються в правильних directory;
• новий dependency update PR відкривається або scheduled run проходить без error;
• команда отримала ownership на наступні runtime deadlines.

Якщо GitHub UI показує помилку для Dependabot, не закривай задачу. Це як зелений dashboard із вимкненим датчиком: виглядає спокійно, але користі мало.

Що НЕ робити

Не шукай тільки python-version: 3.9. Старий runtime може бути в Docker image, devcontainer, runtime.txt, docs або scripts.

Не видаляй 3.9 з matrix без розуміння продуктового контракту. Якщо бібліотека офіційно підтримує клієнтів на Python 3.9, потрібен окремий план. Але dependency automation для репозиторію все одно має бути перевірена.

Не залишай pinning без owner-а. Тимчасовий pin на старій версії швидко стає постійним, якщо не має issue, дедлайну і відповідального.

Не вважай відсутність PR-ів хорошим знаком. Для Dependabot мовчання іноді означає “немає оновлень”, а іноді - “automation не змогла нормально пройти”.

Не роби міграцію одним величезним PR-ом. Краще окремо підняти runtime, окремо виправити package compatibility, окремо прибрати старі docs. Так легше рев’ювити і відкотити.

Висновок

Дедлайн 23 червня 2026 - це короткий, але нормальний runway. За один робочий слот можна знайти репозиторії з Dependabot, перевірити Python 3.9 у CI/tooling, підняти runtime і підтвердити, що update PR-и не зникнуть.

План дій:

1. Візьми список репозиторіїв із .github/dependabot.yml.
2. Відфільтруй Python ecosystems і manifests.
3. Знайди всі згадки Python 3.9 у CI, Docker, devcontainer і docs.
4. Підніми default runtime до підтримуваної версії.
5. Прогони тести й перевір Dependabot run або новий update PR.

Ця міграція не про красу версій. Вона про те, щоб команда не втратила автоматичний сигнал про залежності саме тоді, коли старий runtime уже й так не отримує нормальної підтримки.

Джерела

• GitHub Changelog: Upcoming deprecation of Python 3.9 for Dependabot — https://github.blog/changelog/2026-05-19-upcoming-deprecation-of-python-3-9-for-dependabot/
• GitHub Docs: Configuring Dependabot version updates — https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-version-updates
• GitHub Docs: Dependabot supported ecosystems and repositories — https://docs.github.com/en/code-security/reference/supply-chain-security/supported-ecosystems-and-repositories
• Python Developer Guide: Status of Python versions — https://devguide.python.org/versions/
• Python.org: Python 3.9.25 release page — https://www.python.org/downloads/release/python-3925/