93 lines
No EOL
3.9 KiB
Markdown
93 lines
No EOL
3.9 KiB
Markdown
---
|
||
name: release
|
||
description: Performs a release after PR merge — updates CHANGELOG, creates git tag and GitHub Release. Use when the user says "сделай релиз", "выпусти версию", "опубликуй", "release", "затегай".
|
||
---
|
||
|
||
## Релиз
|
||
|
||
Выполняй релиз строго по шагам. НЕ пропускай шаги.
|
||
|
||
### Шаг 1: Проверки перед релизом
|
||
|
||
- Убедись, что мы на основной ветке (`main` или `master` — проверь какая основная)
|
||
- `git status` — working tree должен быть чистым
|
||
- Если нет → **СТОП**, сообщи пользователю
|
||
|
||
### Шаг 2: Определить версию
|
||
|
||
- Получи последний тег: `git tag --sort=-version:refname | head -1` (например `v2.7.6`)
|
||
- Покажи коммиты с последнего тега: `git log vLAST..HEAD --oneline`
|
||
- Предложи версию на основе коммитов:
|
||
- `feat(...)` → minor bump (например `v2.7.6` → `v2.8.0`)
|
||
- `fix(...)`, `docs(...)`, `chore(...)` → patch bump (`v2.7.6` → `v2.7.7`)
|
||
- Если коммитов с последнего тега нет → **СТОП**, нечего релизить
|
||
- Спроси подтверждение версии у пользователя (через question tool или текстом)
|
||
|
||
### Шаг 3: Обновить CHANGELOG.md
|
||
|
||
Проверь формат changelog. Если файл существует и использует [Keep a Changelog](https://keepachangelog.com/) формат:
|
||
|
||
1. Переименуй `## [Unreleased]` в `## [X.Y.Z] - YYYY-MM-DD` (сегодняшняя дата)
|
||
2. Добавь новый пустой `## [Unreleased]` выше
|
||
3. Заполни секции на основе коммитов:
|
||
- `feat(...)` → `### Added`
|
||
- `fix(...)` → `### Fixed`
|
||
- `chore(...)`, `refactor(...)` → `### Changed`
|
||
- `docs(...)` → можно опустить или `### Changed`
|
||
|
||
Если changelog в другом формате — адаптируй под существующий стиль.
|
||
|
||
### Шаг 4: Коммит changelog
|
||
|
||
```bash
|
||
git add CHANGELOG.md
|
||
git status # проверь staged set — только CHANGELOG.md, без лишнего
|
||
```
|
||
|
||
> `commit` tool НЕ делает `git add` — коммитит только уже staged файлы. Если
|
||
> в индексе лишнее (например `memory-save` stage'нул всё через `git add -A`)
|
||
> — не коммить: сначала `git restore --staged <file>` или не stage'и его
|
||
> изначально. Используй `git add <конкретные-пути>`, НЕ `git add -A`.
|
||
|
||
Затем через `commit` tool (НЕ raw `git commit` — заблокирован deny):
|
||
|
||
```
|
||
commit({ message: "docs: add vX.Y.Z changelog entry" })
|
||
```
|
||
|
||
### Шаг 5: Создать tag
|
||
|
||
Lightweight tag (не annotated):
|
||
|
||
```bash
|
||
git tag vX.Y.Z
|
||
```
|
||
|
||
### Шаг 6: Push
|
||
|
||
```bash
|
||
git push
|
||
git push --tags
|
||
```
|
||
|
||
### Шаг 7: GitHub Release
|
||
|
||
```bash
|
||
gh release create vX.Y.Z --title "vX.Y.Z" --notes "<содержание секции из changelog>"
|
||
```
|
||
|
||
### Шаг 8: Отчёт
|
||
|
||
Сообщи пользователю:
|
||
- Версию релиза
|
||
- Ссылку на GitHub Release
|
||
- Количество коммитов в релизе
|
||
|
||
## Safety rules
|
||
|
||
- НИКОГДА не делай релиз, если working tree не чистый
|
||
- НИКОГДА не делай релиз, если нет новых коммитов с последнего тега
|
||
- НИКОГДА не создавай тег с существующим именем
|
||
- ВСЕГДА спрашивай подтверждение версии у пользователя перед коммитом
|
||
- НЕ обновляй `pyproject.toml` version (в некоторых репо версионирование через tags)
|
||
- НЕ делай `git push --force` |