release please
v16.15.0
Release Please automatiza la generación de CHANGELOG, la creación de lanzamientos de GitHub y cambios de versiones para sus proyectos.
Lo hace analizando su historial de git, buscando mensajes de confirmación convencional y creando relaciones públicas de lanzamiento.
No maneja la publicación para administradores de paquetes ni maneja la gestión compleja de sucursales.
En lugar de publicar continuamente lo que llega a su rama predeterminada, Release-please mantiene los PR de lanzamiento:
Estos PR de versión se mantienen actualizados a medida que se fusiona trabajo adicional. Cuando esté listo para etiquetar una versión, simplemente combine el PR de la versión. Tanto las confirmaciones de squash-merge como de merge funcionan con Release PR.
Cuando se fusiona el PR de versión, la versión por favor sigue los siguientes pasos:
Actualiza su archivo de registro de cambios (por ejemplo CHANGELOG.md ), junto con otros archivos específicos del idioma (por ejemplo, package.json ).
Etiqueta la confirmación con el número de versión.
Crea una versión de GitHub basada en la etiqueta.
Puede saber dónde se encuentra el PR de lanzamiento en su ciclo de vida mediante la etiqueta de estado en el PR mismo:
autorelease: pending es el estado inicial del PR de lanzamiento antes de que se fusione
autorelease: tagged significa que el PR de lanzamiento se ha fusionado y el lanzamiento se ha etiquetado en GitHub
autorelease: snapshot es un estado especial para los cambios de versión de la instantánea
autorelease: published significa que se ha publicado un lanzamiento de GitHub basado en el PR de lanzamiento ( el lanzamiento no agrega automáticamente esta etiqueta, pero lo recomendamos como convención para las herramientas de publicación ).
Release Please supone que está utilizando mensajes de confirmación convencionales.
Los prefijos más importantes que debes tener en cuenta son:
fix: que representa correcciones de errores y se correlaciona con un parche de SemVer.
feat: que representa una característica nueva y se correlaciona con un SemVer menor.
feat!: o fix!: , refactor!: , etc., que representan un cambio importante (indicado por ! ) y dará como resultado un SemVer mayor.
Le recomendamos encarecidamente que utilice squash-merges al fusionar solicitudes de extracción. Un historial lineal de git hace que sea mucho más fácil:
Seguir historial: las confirmaciones se ordenan por fecha de fusión y no se mezclan entre solicitudes de extracción
Buscar y revertir errores: git bisect es útil para rastrear qué cambio introdujo un error
Controle el registro de cambios de liberación: cuando fusiona un PR, es posible que tenga mensajes de confirmación que tengan sentido dentro del alcance del PR, pero que no tengan sentido cuando se fusionen en la rama principal. Por ejemplo, es posible que tenga feat: introduce feature A y luego fix: some bugfix introduced in the first commit . La confirmación fix es en realidad irrelevante para las notas de la versión, ya que nunca se experimentó un error en la rama principal.
Mantenga una rama principal limpia: si usa algo como desarrollo rojo/verde (cree una prueba fallida en la confirmación A, luego corrija en la confirmación B) y fusione (o rebase-fusione), entonces habrá puntos en el tiempo en su rama principal donde las pruebas no pasan.
Release Please le permite representar múltiples cambios en una sola confirmación, usando pies de página:
hazaña: agrega UUID v4 a cripto Esto agrega soporte para UUID v4 a la biblioteca. corrección (utils): Unicode ya no genera una excepción PiperOrigin-RevId: 345559154 CAMBIO ÚLTIMO: el método de codificación ya no arroja. Enlace fuente: googleapis/googleapis@5e0dcb2 hazaña (utils): actualiza la codificación para que sea compatible con Unicode PiperOrigin-RevId: 345559182 Enlace fuente: googleapis/googleapis@e5eef86
El mensaje de confirmación anterior contendrá:
una entrada para la función "agrega UUID v4 a criptografía" .
una entrada para la corrección "unicode ya no genera excepción" , junto con una nota de que es un cambio importante.
una entrada para la función "actualizar codificación para admitir Unicode" .
Cuando una confirmación a la rama principal tiene Release-As: xxx (no distingue entre mayúsculas y minúsculas) en el cuerpo de la confirmación , Release Please abrirá una nueva solicitud de extracción para la versión especificada.
Ejemplo de confirmación vacía:
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" da como resultado el siguiente mensaje de confirmación:
tarea: versión 2.0.0 Lanzamiento como: 2.0.0
Si fusionó una solicitud de extracción y desea modificar el mensaje de confirmación utilizado para generar las notas de la versión para esa confirmación, puede editar el cuerpo de las solicitudes de extracción fusionadas y agregar una sección como:
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
La próxima vez que se ejecute Release Please, utilizará esa sección de anulación como mensaje de confirmación en lugar del mensaje de confirmación combinado.
Lanzamiento: crea una solicitud de extracción de lanzamiento después de notar que la rama predeterminada contiene "unidades liberables" desde el último lanzamiento. Una unidad liberable es una confirmación de la rama con uno de los siguientes prefijos: "feat", "fix" y "deps". (Una confirmación de "tarea" o "construcción" no es una unidad liberable).
Algunos idiomas tienen su configuración de unidad liberable específica. Por ejemplo, "docs" es un prefijo para unidades liberables en Java y Python.
autorelease: pending o autorelease: triggered en un PR antiguo Verifique las solicitudes de extracción existentes etiquetadas con autorelease: pending o autorelease: triggered . Debido a fallas en la API de GitHub, es posible que la etiqueta no se haya eliminado correctamente en una versión anterior y Release Please piense que la versión anterior aún está pendiente. Si está seguro de que no hay ninguna publicación pendiente, elimine la etiqueta autorelease: pending o autorelease: triggered .
Para los usuarios de la aplicación GitHub, Release Please no creará una nueva solicitud de extracción si existe una solicitud de extracción etiquetada como autorelease: pending . Para confirmar este caso, busque una solicitud de extracción con la etiqueta. (Es muy probable que sea la última solicitud de extracción de versión). Si encuentra una solicitud de extracción de versión con la etiqueta y no se va a publicar (o ya se ha publicado), elimine la etiqueta autorelease: pending y vuelva a ejecutar Liberar por favor.
Si cree que Release Please no creó un PR de lanzamiento después de que se fusionó una solicitud de extracción con una unidad liberable, vuelva a ejecutar release-please . Si está utilizando la aplicación GitHub, agregue la etiqueta release-please:force-run a la solicitud de extracción fusionada. Si está utilizando la acción, busque la invocación fallida y vuelva a intentar ejecutar el flujo de trabajo. Release Please procesará la solicitud de extracción inmediatamente para encontrar unidades liberables.
Release Please automatiza los lanzamientos para los siguientes tipos de repositorios:
| tipo de lanzamiento | descripción |
|---|---|
bazel | Un módulo Bazel, con un MODULE.bazel y un CHANGELOG.md |
dart | Un repositorio con pubspec.yaml y CHANGELOG.md |
elixir | Un repositorio con mix.exs y CHANGELOG.md |
go | Un repositorio con CHANGELOG.md |
helm | Un repositorio con Chart.yaml y CHANGELOG.md |
java | Una estrategia que genera una versión SNAPSHOT después de cada lanzamiento. |
krm-blueprint | Un paquete kpt, con 1 o más archivos KRM y un CHANGELOG.md |
maven | Estrategia para proyectos Maven, genera una versión SNAPSHOT después de cada lanzamiento y actualiza pom.xml automáticamente |
node | Un repositorio Node.js, con package.json y CHANGELOG.md |
expo | Un repositorio React Native basado en Expo, con package.json, app.json y CHANGELOG.md |
ocaml | Un repositorio OCaml, que contiene 1 o más archivos opam o esy y un CHANGELOG.md |
php | Un repositorio con un compositor.json y un CHANGELOG.md |
python | Un repositorio de Python, con setup.py, setup.cfg, CHANGELOG.md y, opcionalmente, pyproject.toml y <project>/__init__.py |
ruby | Un repositorio con una versión.rb y un CHANGELOG.md |
rust | Un repositorio de Rust, con un Cargo.toml (ya sea como caja o espacio de trabajo, aunque tenga en cuenta que los espacios de trabajo requieren una versión controlada por manifiesto y el complemento "cargo-workspace") y un CHANGELOG.md |
sfdx | Un repositorio con sfdx-project.json y CHANGELOG.md |
simple | Un repositorio con un version.txt y un CHANGELOG.md |
terraform-module | Un módulo terraform, con una versión en README.md y CHANGELOG.md |
Hay una variedad de formas en que puede implementar el lanzamiento:
La forma más sencilla de ejecutar Release Please es como una acción de GitHub. Consulte googleapis/release-please-action para obtener instrucciones de instalación y configuración.
Consulte Ejecución de la versión CLI por favor para conocer todas las opciones de configuración.
Hay una aplicación probot disponible que le permite implementar Release Please como una aplicación GitHub. Consulte github.com/googleapis/repo-automation-bots para obtener instrucciones de instalación y configuración.
Lanzamiento: mira las confirmaciones desde su última etiqueta de lanzamiento. Es posible que pueda o no encontrar sus versiones anteriores. La forma más sencilla de incorporar su repositorio es iniciar una configuración de manifiesto.
Release Please proporciona varias opciones de configuración para permitir personalizar su proceso de lanzamiento. Consulte customizing.md para obtener más detalles.
Release Please también admite la publicación de múltiples artefactos desde el mismo repositorio. Ver más en manifest-releaser.md.
Nuestras bibliotecas cliente siguen el calendario de lanzamiento de Node.js. Las bibliotecas son compatibles con todas las versiones activas y de mantenimiento actuales de Node.js.
Hay disponibles bibliotecas cliente destinadas a algunas versiones de Node.js al final de su vida útil y se pueden instalar mediante etiquetas npm dist-tags. Las etiquetas dist siguen la convención de nomenclatura legacy-(version) .
Las versiones heredadas de Node.js se admiten como mejor esfuerzo:
Las versiones heredadas no se probarán en integración continua.
Es posible que no se puedan realizar copias de seguridad de algunos parches de seguridad.
Las dependencias no se mantendrán actualizadas y las funciones no tendrán soporte.
legacy-8 : instala bibliotecas cliente desde esta etiqueta dist para versiones compatibles con Node.js 8.
Esta biblioteca sigue el control de versiones semántico.
¡Bienvenidos aportes! Consulte la Guía de contribución.
Para obtener más información sobre el diseño de la biblioteca, consulte diseño.
Para problemas comunes y ayuda para solucionar problemas de configuración, consulte Solución de problemas.
Apache versión 2.0
Ver LICENCIA
Este no es un producto oficial de Google.
