| name | release-notes |
| description | This skill creates release notes for new release by reading git commit log. Use it only when explicitly specified |
Release notes
Когда нужно выпустить новый релиз, в репозитории нужно изменить файл install/release-notes.md (путь относительно корня репозитория)
Для того, чтобы собрать данные, нужно использовать git log и вызвать команду
set LC_ALL=C.UTF-8
set TAGNAME=%1
git --no-pager log --pretty="* %%s" --no-merges %TAGNAME%..HEAD
где переменная TAGNAME должна быть git-тэгом предыдущего релиза. Результатом выполнения команды будут тексты коммитов, между TAGNAME и текущим состоянием ветки.
Ты должен запросить у пользователя тег предыдущей версии, либо пользователь тебе сообщит его в промпте сразу.
Далее, ты должен прочитать тексты коммитов, в них могут встречаться ссылки на github issues в виде указания номера задачи через решетку, например вот так:
fixes #1234 bla-bla-bla
Текст коммита также может не содержать упоминания задачи, или быть вовсе техническим/промежуточным коммитом, который в release notes попадать не должен, т.к. не описывает конечное изменение.
Твоя задача и цель - взять тексты коммитов и вывести из них изменения в версии, которые будут включены в файл install/release-notes.md.
Те коммиты, которые содержат ссылки на github - пойти на github в соответствующую задачу в репозитории https://github.com/EvilBeaver/OneScript/issues/<НомерЗадачи> и прочитать ее суть.
Те коммиты, которые ссылок на гитхаб не содержат, ты должен просто прочитать и решить - стоит их включать в release-notes или нет, содержат ли они описание конкретной сделанной функциональности, или это промежуточный, технический и не требующий публикации коммит.
Далее, ты должен сделать итоговый дайджест того, что было сделано в версии и записать это в файл install/release-notes.md. Каждая задача это отдельный bullet-point, причем ссылки на github должны быть сделаны в markdown реальными кликабельными ссылками.
Формат файла release-notes
В начале записывается заголовок "Версия <НомерВерсии>. Какая сейчас конкретно версия ты должен посмотреть в файле Jenkinsfile в параметре VersionPrefix и взять его.
Далее идет перечень сделанных задач, как описано выше.
Задачи разбиваются на две группы: исправление ошибок и новые возможности. Соответственно в release notes добавляются два раздела уровня "заголовок 2" для "Новые возможности" и "Исправление ошибок". Если задач по какой-то категории нет (например, были только исправления, а новых фич не было), то соответствующий раздел не добавляется в файл совсем.
Instructions
- Определи текущую выпускаемую версию, прочитав файл Jenkinsfile и его параметр VersionPrefix в самом начале
- Определи тег предыдущей версии. Для этого запроси его у пользователя, если тег не был сразу задан в промпте
- Выполни команду gitlog, как показано выше, для получения истории коммитов между версиями
- Составь дайджест изменений и запиши их в install/release-notes.md
