Да, это хорошая практика — но с важным нюансом для наших репозиториев: бо́льшую часть этих меток мы уже получаем бесплатно, и хардкодить их в Dockerfile нам почти не нужно. Разберу по частям.
Зачем эти метки вообще. Самая важная — org.opencontainers.image.source: по ней GitHub привязывает ghcr-образ к репозиторию (пакет появляется на странице репо, наследует права и видимость — для публичного репо образ автоматически становится публичным). Остальные (description, licenses, title) показываются в UI реестра и помогают инструментам инвентаризации.
Почему у нас это уже работает. Оба наших image-пайплайна — UI и свежий API из PR #78 — используют docker/metadata-action, и строка labels: ${{ steps.meta.outputs.labels }} в build-push-action автоматически генерирует весь стандартный набор: title и description из метаданных репозитория, source/url, licenses из файла лицензии, плюс динамические version, revision (SHA коммита!) и created — то, что в Dockerfile захардкодить нельзя в принципе. Это строго лучше статических LABEL: метки всегда актуальны. В лаборатории вы прописали их руками, вероятно, до или вместо metadata-action — для наших конвейеров дублировать их в Dockerfile смысла нет.
Чего автоматика не покрывает: authors и documentation — их metadata-action сам не выводит. И ещё одна зависимость: description берётся из описания репозитория на GitHub — если оно пустое, метка будет пустой. Проверю и закрою оба пробела:
Итоговый ответ на ваш вопрос:
Да, OCI-метки — хорошая практика, но правильное место для них у нас — не Dockerfile, а workflow. Резюме:
| Метка | Откуда берётся у нас |
|---|---|
title, description | metadata-action ← название и описание репозитория |
source, url | metadata-action ← автоматически (это и привязывает пакет к репо) |
licenses | metadata-action ← LICENSE-файл |
version, revision, created | metadata-action ← тег/SHA/время сборки — в Dockerfile такое не захардкодишь |
authors, documentation | единственные две, что добавил руками — сейчас в PR #78 |
Подход лаборатории (LABEL в Dockerfile) был правильным по духу, но статичным: revision и version там не живут, а description приходится синхронизировать руками. Через metadata-action всё это динамическое и не расходится с реальностью.
Что сделано и что осталось:
- API-образ (PR #78): добавлены
authorsиdocumentation— одним коммитом в открытый PR. - UI-образ: та же двухстрочная добавка просится в
deploy.yamlUI-репозитория — заберу её попутно в любой следующий UI-PR, отдельного не заслуживает. - Мелочь вам на заметку: описание репозитория analytics ещё упоминает FastAPI — оно теперь течёт прямо в метку образа; после вывода Python обновите одной командой
gh repo edit --description.
PR #78 в финальном составе: контейнеризация + мультиарх-публикация + статический UID + OCI-метки. Жду вашего merge для выкатки на сервер.
Сделаю обе вещи: разберу комментарии на #75 и проведу исследование betterleaks. Сразу скажу: к «более новым прогрессивным версиям» инструментов для сканирования секретов я отношусь с максимальной настороженностью — такой инструмент по определению читает ваши секреты, и подменный «преемник» популярного сканера — классический вектор атаки на цепочку поставок. Проверю тщательно и ничего не буду устанавливать до вердикта. Сначала комментарии:
Шаблон не совпал — посмотрю фактическое содержимое файла агента:
Профиль ясен. Два оставшихся практических вопроса — ставится ли через mise и есть ли сканирование staged-изменений:
Готово по обоим пунктам.
Замечания на #75 — с поучительным поворотом
Gemini ошибся в двух из трёх, и эмпирика это доказала: флаги gitleaks protect --staged и lefthook run --all-files существуют в установленных версиях — Sonnet-агент в своём отчёте не выдумывал, его живые прогоны были настоящими. Бот рассуждал по устаревшим докам. Третье замечание (гонка двух ruff-команд при parallel: true) — валидное, применено: один последовательный job. Все треды отвечены с доказательствами и зарезолвлены.
Исследование betterleaks — вердикт: легитимен и принят
Моя начальная паранойя (подменный «преемник» сканера секретов — идеальный вектор атаки) оказалась уместной процедурой с чистым результатом:
- Легитимность доказана: официальный README gitleaks сам объявляет «Gitleaks is feature complete… I’m shifting my focus to Betterleaks», а топ-контрибьютор betterleaks —
zricethezav, автор gitleaks. Тот же MIT. - Зрелость достаточная: v1.5.0, 10 релизов; главное — оставаться на gitleaks значило бы принять замороженный инструмент в момент внедрения.
- Подходит нам по всем пунктам: ставится через mise (aqua), официальный pre-commit режим
betterleaks git --pre-commit --redact --staged. - Проверен боем: подсаженный формат-валидный GitHub-токен пойман (
leaks found: 1, exit 1, коммит заблокирован), а канонический AWS-пример из документации корректно в allowlist — мой первый «провальный» тест был как раз признаком качества инструмента. Валидацию секретов (фича с HTTP-проверками) не включаем — ничего никуда не отправляется.
PR #75 обновлён: lefthook + betterleaks, с комментарием-обоснованием. Хорошее чутьё на ссылку — преемник от автора в момент заморозки оригинала — редкий случай, когда «новое и прогрессивное» оказывается правильным выбором.