release please скачайте - release please загрузите исходный код

release please

Другой исходный код

v16.15.0

Скачать

Отпустите, пожалуйста

Release Please автоматизирует генерацию CHANGELOG, создание выпусков GitHub и обновление версий для ваших проектов.

Он делает это путем анализа вашей истории git, поиска обычных сообщений о фиксации и создания PR-запросов на выпуск.

Он не обрабатывает публикацию для менеджеров пакетов и не обрабатывает сложное управление ветвями.

Что такое релизный PR?

Вместо того, чтобы постоянно выпускать то, что попало в вашу ветку по умолчанию, Release-Please поддерживает Release PR:

Эти выпуски PR обновляются по мере объединения дополнительных работ. Когда вы будете готовы пометить релиз, просто объедините PR релиза. И сквош-слияние, и слияние коммитов работают с Release PR.

При объединении Release PR компания Release-Please выполняет следующие шаги:

Обновляет файл журнала изменений (например, CHANGELOG.md ), а также файлы других языков (например, package.json ).
Помечает коммит номером версии
Создает выпуск GitHub на основе тега.

Вы можете определить, на каком этапе жизненного цикла находится релиз PR, по метке статуса на самом PR:

autorelease: pending — это начальное состояние Release PR перед его объединением.
autorelease: tagged означает, что Release PR был объединен и релиз помечен в GitHub
autorelease: snapshot — это особое состояние для обновлений версии снимка.
autorelease: published означает, что релиз GitHub был опубликован на основе Release PR ( release-please не добавляет этот тег автоматически, но мы рекомендуем его в качестве соглашения для инструментов публикации ).

Как мне написать свои коммиты?

Release Please предполагает, что вы используете обычные сообщения фиксации.

Наиболее важные префиксы, которые вам следует иметь в виду:

fix: представляет исправления ошибок и соответствует патчу SemVer.
feat: представляет собой новую функцию и соответствует второстепенной версии SemVer.
feat!: или fix!: , refactor!: и т. д., которые представляют собой критическое изменение (обозначенное ! ) и приведут к серьезному изменению SemVer.

Линейная история коммитов git (используйте сквош-слияние)

Мы настоятельно рекомендуем вам использовать сквош-слияния при объединении запросов на включение. Линейная история git значительно упрощает:

Следить за историей — коммиты сортируются по дате слияния и не смешиваются между запросами на включение
Находите и устраняйте ошибки — git bisect помогает отслеживать, какое изменение привело к ошибке.
Контролируйте журнал изменений «выпустите, пожалуйста» — при объединении PR у вас могут появиться сообщения о фиксации, которые имеют смысл в рамках PR, но не имеют смысла при объединении в основную ветку. Например, у вас может быть feat: introduce feature A , а затем fix: some bugfix introduced in the first commit . fix на самом деле не имеет отношения к примечаниям к выпуску, поскольку в основной ветке никогда не было ошибок.
Сохраняйте чистую основную ветку — если вы используете что-то вроде красной/зеленой разработки (создайте неудачный тест в коммите A, затем исправьте в коммите B) и выполните слияние (или перебазирование-слияние), тогда в вашей основной ветке будут моменты времени где тесты не проходят.

Что делать, если мой PR содержит несколько исправлений или функций?

Release Please позволяет представить несколько изменений в одном коммите, используя нижние колонтитулы:

 подвиг: добавляет UUID v4 в криптографию

Это добавляет в библиотеку поддержку UUID версии 4.

fix(utils): Юникод больше не выдает исключение
  PiperOrigin-RevId: 345559154
  BREAKING-CHANGE: метод encode больше не выдает.
  Ссылка на источник: googleapis/googleapis@5e0dcb2

feat(utils): обновить кодировку для поддержки Юникода
  PiperOrigin-RevId: 345559182
  Ссылка на источник: googleapis/googleapis@e5eef86

Приведенное выше сообщение фиксации будет содержать:

запись для функции «добавляет UUID v4 в криптографию» .
запись об исправлении «Юникод больше не генерирует исключение» вместе с примечанием о том, что это критическое изменение.
запись для функции «обновить кодировку для поддержки Unicode» .

️ Важно: дополнительные сообщения необходимо добавлять в конец коммита.

Как изменить номер версии?

Если в теле коммита в основной ветке есть Release-As: xxx (без учета регистра), Release Please откроет новый запрос на включение для указанной версии.

Пример пустого коммита:

git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" приводит к следующему сообщению фиксации:

 рутинная работа: выпуск 2.0.0

Релиз-Как: 2.0.0

Как я могу исправить примечания к выпуску?

Если вы объединили запрос на включение и хотите изменить сообщение о фиксации, используемое для создания примечаний к выпуску для этого коммита, вы можете отредактировать тело объединенных запросов на включение и добавить такой раздел, как:

BEGIN_COMMIT_OVERRIDE
feat: add ability to override merged commit message

fix: another message
chore: a third message
END_COMMIT_OVERRIDE

При следующем запуске Release Please он будет использовать этот раздел переопределения в качестве сообщения о фиксации вместо объединенного сообщения о фиксации.

️ Важно: эта функция не будет работать с простыми слияниями, поскольку команда Release не знает, к какому коммиту(ам) применить переопределение. Вместо этого мы рекомендуем использовать сквош-слияние.

Бот Release Please не создает PR релиза. Почему?

Шаг 1. Убедитесь, что выпускаемые единицы объединены

Release Please создает запрос на выпуск версии после того, как обнаруживает, что ветка по умолчанию содержит «выпускаемые модули» с момента последнего выпуска. Выпускаемый модуль — это коммит в ветку с одним из следующих префиксов: «feat», «fix» и «deps». (Коммит «работа» или «сборка» не является выпускаемой единицей.)

Некоторые языки имеют свою особую конфигурацию выпускаемых модулей. Например, «документы» — это префикс для выпускаемых модулей в Java и Python.

Шаг 2. Убедитесь, что в старом PR нет ярлыка `autorelease: pending` или `autorelease: triggered`

Проверьте существующие запросы на включение, помеченные меткой autorelease: pending или autorelease: triggered . Из-за сбоев API GitHub возможно, что тег не был удален правильно в предыдущем выпуске, и Release Please считает, что предыдущий выпуск все еще находится на рассмотрении. Если вы уверены, что ожидающих выпусков нет, удалите метку autorelease: pending или autorelease: triggered .

Для пользователей приложения GitHub Release Please не будет создавать новый запрос на включение, если существует существующий запрос на включение, помеченный как autorelease: pending . Чтобы подтвердить этот случай, найдите запрос на включение с меткой. (Весьма вероятно, что это последний запрос на включение выпуска.) Если вы нашли запрос на включение выпуска с меткой, и он не будет выпущен (или уже выпущен), удалите метку autorelease: pending и повторно запустите Release Please.

Шаг 3. Повторите выпуск, пожалуйста.

Если вы считаете, что Release Please пропустил создание PR-запроса на выпуск после объединения запроса на вытягивание с выпускаемым модулем, перезапустите release-please . Если вы используете приложение GitHub, добавьте метку release-please:force-run в объединенный запрос на извлечение. Если вы используете это действие, найдите неудачный вызов и повторите запуск рабочего процесса. Release Please немедленно обработает запрос на включение, чтобы найти подлежащие выпуску модули.

Поддерживаемые типы стратегий (языков)

Release Please автоматизирует выпуски для следующих типов репозиториев:

тип выпуска	описание
`bazel`	Модуль Bazel с MODULE.bazel и CHANGELOG.md.
`dart`	Репозиторий с pubspec.yaml и CHANGELOG.md.
`elixir`	Репозиторий с файлами mix.exs и CHANGELOG.md.
`go`	Репозиторий с CHANGELOG.md.
`helm`	Репозиторий с Chart.yaml и CHANGELOG.md.
`java`	Стратегия, которая генерирует версию SNAPSHOT после каждого выпуска.
`krm-blueprint`	Пакет kpt с 1 или несколькими файлами KRM и файлом CHANGELOG.md.
`maven`	Стратегия для проектов Maven: генерирует версию SNAPSHOT после каждого выпуска и автоматически обновляет `pom.xml`
`node`	Репозиторий Node.js с package.json и CHANGELOG.md.
`expo`	Репозиторий React Native на базе Expo с package.json, app.json и CHANGELOG.md.
`ocaml`	Репозиторий OCaml, содержащий 1 или несколько файлов opam или esy и файл CHANGELOG.md.
`php`	Репозиторий с композитором.json и CHANGELOG.md.
`python`	Репозиторий Python с файлами setup.py, setup.cfg, CHANGELOG.md и, при необходимости, pyproject.toml и <project>/__init__.py.
`ruby`	Репозиторий с файлами version.rb и CHANGELOG.md.
`rust`	Репозиторий Rust с Cargo.toml (либо в виде крейта, либо рабочей области, хотя обратите внимание, что для рабочих областей требуется выпуск, управляемый манифестом, и плагин «cargo-workspace») и CHANGELOG.md.
`sfdx`	Репозиторий с файлами sfdx-project.json и CHANGELOG.md.
`simple`	Репозиторий с файлами version.txt и CHANGELOG.md.
`terraform-module`	Модуль terraform с версией в README.md и CHANGELOG.md.

Настройте выпуск, пожалуйста

Существует несколько способов развертывания релиза:

Действие GitHub (рекомендуется)

Самый простой способ запустить Release Please — это действие GitHub. Инструкции по установке и настройке см. в googleapis/release-please-action.

Запуск через CLI

Пожалуйста, ознакомьтесь со всеми параметрами конфигурации в разделе «Запуск CLI-релиза».

Установите приложение GitHub

Доступно приложение-робот, которое позволяет развернуть Release Please как приложение GitHub. Инструкции по установке и настройке см. на сайте github.com/googleapis/repo-automation-bots.

Начальная загрузка вашего репозитория

Release Please просматривает коммиты с момента вашего последнего тега релиза. Он может или не сможет найти ваши предыдущие выпуски. Самый простой способ подключить ваш репозиторий — загрузить конфигурацию манифеста.

Настройка выпуска, пожалуйста

Release Please предоставляет несколько вариантов конфигурации, позволяющих настроить процесс выпуска. Пожалуйста, посетите сайт customizing.md для получения более подробной информации.

Поддержка монорепозиториев через конфигурацию манифеста

Release Please также поддерживает выпуск нескольких артефактов из одного репозитория. Подробную информацию можно найти на манифесте-releaser.md.

Поддерживаемые версии Node.js

Наши клиентские библиотеки следуют графику выпуска Node.js. Библиотеки совместимы со всеми текущими активными и поддерживающими версиями Node.js.

Клиентские библиотеки, предназначенные для некоторых устаревших версий Node.js, доступны и могут быть установлены через npm dist-tags. Dist-теги соответствуют соглашению об именах legacy-(version) .

Устаревшие версии Node.js поддерживаются по мере возможности: