Lanzar y mantener las acciones

Introducción

Después de que creas una acción, querrás seguir lanzando características nuevas mientras trabajas con las contribuciones de la comunidad. Este tutorial describe un proceso de ejemplo que puedes seguir para lanzar y mantener las acciones en los proyectos de código abierto. El ejemplo:

• Aprovecha las GitHub Actions para la integración continua, actualizaciones de dependencias, administración de lanzamientos y automatización de tareas.
• Proporciona confianza a través de las pruebas automatizadas e insignias de compilación.
• Indica cómo puede utilizarse la acción, idealmente, como parte de un flujo de trabajo más amplio.
• Señala qué tipo de contribuciones de la comunidad recibes. (Por ejemplo: propuestas, solicitudes de cambios o reportes de vulnerabilidades.)

Para obtener un ejemplo aplicado de este proceso, vea actions/javascript-action.

Desarrollar y lanzar las acciones

En esta sección, debatimos un proceso de ejemplo para desarrollar y lanzar acciones y mostramos cómo utilizar las GitHub Actions para automatizar el proceso.

Acerca de las acciones de JavaScript

Las acciones de JavaScript son repositorios de Node.js con metadatos. Sin embargo, las acciones de JavaScript tienen propiedades adicionales comparadas con los proyectos tradicionales de Node.js:

• Los paquetes dependientes se confirman junto con el código, habitualmente de forma compilada y minificada. Esto significa que las compilaciones automatizadas y contribuciones seguras de la comunidad, son importantes.

• Muchas de las acciones utilizan las API de GitHub y de terceros, así que recomendamos hacer pruebas robustas de extremo a extremo.

Configurar los flujos de trabajo de GitHub Actions

Para apoyar el proceso de desarrollo en la siguiente sección, agrega dos flujos de trabajo de GitHub Actions a tu repositorio:

1. Agregue un flujo de trabajo que se desencadene cuando se inserte una confirmación en una rama de características o main, o bien cuando se cree una solicitud de incorporación de cambios. Configura el flujo de trabajo para que ejecute tus pruebas de unidad y de integración. Para obtener un ejemplo, vea este flujo de trabajo.
2. Agrega un flujo de trabajo que se active cuando se publique o edite un lanzamiento. Configura el flujo de trabajo para garantizar que cuentes con etiquetas semánticas. Puede usar una acción como JasonEtco/build-and-tag-action para compilar y agrupar el archivo de JavaScript y los metadatos, y forzar la inserción de etiquetas semánticas principales, secundarias y de revisión. Para más información sobre las etiquetas semánticas, vea "Acerca del control de versiones semántico".

Proceso de desarrollo ejemplo

Aquí tienes un proceso de ejemplo que puedes seguir para ejecutar pruebas automáticas, crear una versión y publicar tu acción.

1. Realiza trabajo de características en las ramas por flujo de GitHub. Para obtener más información, vea «Flujo de GitHub».

   • Cuando se suba una confirmación a la rama de característica, tu flujo de trabajo de pruebas ejecutará las pruebas automáticamente.

2. Cree solicitudes de incorporación de cambios en la rama main para iniciar debates y revisiones, y realizar la combinación cuando estén listas.

   • Cuando se abre una solicitud de cambios, ya sea desde una rama o una bifurcación, tu flujo de trabajo de prueba volverá a ejecutar las pruebas, esta vez, con la confirmación de fusión.

   • Nota: Por motivos de seguridad, los flujos de trabajo desencadenados por pull_request desde las bifurcaciones tienen permisos GITHUB_TOKEN restringidos y no tienen acceso a los secretos. Si las pruebas u otros flujos de trabajo desencadenados tras la solicitud de incorporación de cambios necesitan acceso a los secretos, considere la posibilidad de usar otro evento, como un desencadenador manual o pull_request_target. Para obtener más información, vea «Eventos que desencadenan flujos de trabajo».

3. Crea un lanzamiento con etiquetado semántico. Para obtener más información, consulta "Administrar lanzamientos en un repositorio" ".

   • Cuando se publica o edita un lanzamiento, el flujo de trabajo de este se encargará automáticamente de la compilación y ajuste de etiquetas.

   • Se recomienda crear versiones mediante etiquetas con versiones semánticas (por ejemplo, v1.1.3) y mantener las etiquetas principales (v1) y secundarias (v1.1) actuales en la confirmación adecuada más reciente. Para obtener más información, consulta "Acercad e las acciones personalizadas" y "Acerca del control de versiones semántico.

Resultados

A diferencia de otras estrategias de administración de versiones automatizadas, este proceso no confirma de forma intencionadas las dependencias en la rama main, solo en las confirmaciones de versión etiquetadas. Al hacerlo, se anima a los usuarios de la acción a hacer referencia a etiquetas con nombre o sha, y ayuda a garantizar la seguridad de las solicitudes de incorporación de cambios de terceros al realizar personalmente la compilación durante una versión.

El uso de versiones semánticas implica que los usuarios de tus acciones pueden fijar sus flujos de trabajo a una versión y saber que podrían seguir recibiendo las últimas características constantes y estables, dependiendo de su nivel de confort.

Trabajar con la comunidad

GitHub Enterprise Server proporciona herramientas y guías para ayudarte a trabajar con la comunidad de código abierto. Aquí tienes algunas herramientas que te recomendamos configurar para tener una comunicación bidireccional saludable. Al proporcionar las siguientes señales a la comunidad, motivas a los demás a utilizar, modificar y contribuir con tu acción:

• Mantenga un README con una gran cantidad de ejemplos de uso e instrucciones. Para obtener más información, vea «Acerca de los archivos README».
• Incluya un distintivo de estado de flujo de trabajo en el archivo README. Para obtener más información, vea «Adición de un distintivo de estado de flujo de trabajo». Visite también shields.io para obtener información sobre otros distintivos que puede agregar.
• Mantenga las incidencias actualizadas mediante acciones como actions/stale.

Información adicional

Los ejemplos donde se emplean patrones similares incluyen:

• github/super-linter
• octokit/request-action
• actions/javascript-action