Python-semantic-release + Woodpecker CI: Как поддерживать сборки RC и вести сгруппированный журнал изменений для финальн ⇐ Python

[Anonymous]

Я изо всех сил пытаюсь разработать правильный рабочий процесс CI/выпуска, используя python-semantic-release вместе с Woodpecker CI, и мне кажется, что я неправильно смешиваю концепции.
Мои цели:

• Набрать несколько коммитов (feat/fix/chore/etc.)
• Пусть они отображаются в одной сгруппированной версии в журнале изменений (например, v2.1.0)
• По-прежнему можно создавать и использовать версии RC-сборок (

  Код: Выделить всё

  v2.1.0-rc.1

  , rc.2 и т. д.) для тестирования перед выпуском
• Поддерживать чистый и предсказуемый поток CI/CD

Что я пробовал

1. dev + main с semantic-release на обоих

• Ветки функций → сжать слияние с dev
• Запустить semantic-release на dev → сгенерировать vX.Y.Z-rc.N
• Затем объединить dev → main и снова запустить semantic-release

Проблема:

• Каждый RC обновляет версию и обновляет журнал изменений
• При слиянии с основной коммиты уже «израсходованы»
• Окончательный журнал изменений фрагментирован по нескольким записям RC, а не сгруппирован

2. Рабочий процесс Rebase + сквош

• Squash фиксируется в разработке
• Перебазируйте версию на главную

Проблема:

• Нарушается история git
• semantic-release не может правильно найти предыдущие теги
• Версии сбрасываются или возвращаются назад (поскольку теги не находятся в родословной)

3. Добавление ветки Release/*

• Код: Выделить всё

  dev

  → Release/x.y (объединить фиксацию)
• Запустить semantic-release для Release/x.y → RC-версии
• Объединить Release/x.y → main

Проблема:

• То же, что и раньше: выпуски RC уже обновляют журнал изменений и используют коммиты
• Окончательный выпуск на основном НЕ группирует все изменения в одной версии

Основная проблема
Это выглядит следующим образом:

Выполнение semantic-release в предварительных ветках (dev или Release/*) «израсходует» коммиты, поэтому их невозможно сгруппировать позже в окончательном выпуске в основном.

В то же время мне все еще нужны:

• Версионные артефакты для тестирования (например, образы Docker для приложения FastAPI)
• Возможность тестировать определенные функции или комбинации перед выпуском

Дополнительное ограничение
Если я перестану использовать версии RC для разработки, то:

• Я теряю правильное управление версиями для тестовых развертываний.
• Я могу развернуть только с помощью SHA фиксации, который кажется менее структурированным, чем семантические версии.

Чего я хочу достичь
Идеальный рабочий процесс:

• Разрешить непрерывную интеграцию функций dev
• Разрешить создание версий RC-сборок для тестирования (например, v2.1.0-rc.1)
• Убедитесь, что при выпуске в основной журнал изменений полностью сгруппирован:

Код: Выделить всё

## v2.1.0

### Features
- feature A
- feature B

### Fixes
- fix C

(не разбиваться на несколько записей RC)

Вопросы

• Каков правильный способ структурирования ветвей и CI с помощью python-semantic-release для поддержки обоих:
  • сборок RC
  • Окончательный журнал изменений сгруппирован?
• Должен ли семантический выпуск:
  • запускаться только в основном?
  • или также в предварительных версиях, но с ограниченным количеством плагинов?
• Как правильно обрабатывать тестовые развертывания?
  • Использовать образы SHA фиксации?
  • Или все еще полагаться на версии RC?
• Существует ли рекомендуемый шаблон для этого (особенно с Woodpecker CI), или я принципиально неправильно использую семантический выпуск?

Технологический стек

• python-semantic-release
• Woodpecker CI
• Приложение FastAPI (Dockerized)
• Обычные коммиты

Будем очень признательны за любые рекомендации и примеры из реальной жизни >