Las Acciones de GitHub ofrecen una solución conveniente y completa para construir pipelines de CI. Las acciones consisten en pasos componibles controlados por archivos YAML que se guardan en tu repositorio de código. Ven y aprende cómo realizar tareas que son comúnmente requeridas en bases de código Node.js modernas, como la instalación de paquetes, el linting, la ejecución de pruebas como parte de las solicitudes de extracción, la construcción de imágenes Docker y la implementación cuando el código se fusiona en la rama principal.
Video Summary and Transcription
Las Acciones de GitHub permiten realizar tareas de integración continua, definidas en archivos YAML, que pueden ser versionadas y revisadas a través de solicitudes de extracción. Los flujos de trabajo pueden ser activados por eventos como solicitudes de extracción o fusiones, y los pasos pueden hacer referencia a repositorios externos de GitHub. Se pueden construir y desplegar contenedores Docker utilizando las Acciones de GitHub, con la configuración y el despliegue definidos en archivos YAML. Los valores pueden ser utilizados y compartidos entre las Acciones de GitHub, y los componentes internos de Node.js pueden ser instrumentados para el monitoreo de rendimiento.
Available in English
1. Introducción a las Acciones de GitHub
Short description:
Hola, soy Thomas Hunter y bienvenidos a mi charla, Acciones de GitHub para aplicaciones Node. En esta charla, daré una visión general de las acciones de GitHub, que te permiten ejecutar tareas de integración continua relacionadas con tu base de código. Las acciones de GitHub se definen utilizando archivos YAML y se pueden versionar y revisar a través de solicitudes de extracción. Son componibles, lo que te permite construir gráficos de dependencia y ejecutar código en paralelo. Los pasos pueden hacer referencia a repositorios externos de GitHub.
Hola, soy Thomas Hunter y bienvenidos a mi charla, Acciones de GitHub para aplicaciones Node. Y el contenido de esta charla se basa en un libro que publiqué recientemente llamado Sistemas Distribuidos con Node. Bien, vamos a sumergirnos en ello. Primero, vamos a ver una visión general de las acciones de GitHub. Es posible que te preguntes qué es una acción de GitHub. Bueno, es una forma de ejecutar tareas de integración continua relacionadas con tu base de código. Y es realmente conveniente si tu código ya está alojado en GitHub, lo cual parece ser el caso de la mayoría de los repositorios en estos días. La forma en que funciona es que finalmente asigna una máquina virtual para ti en algún lugar, y luego ejecuta un montón de código para ti una vez que se ha activado una acción de GitHub. Y en cuanto a la facturación, se basa en minutos. Si tienes una cuenta gratuita, obtienes 2000 minutos al mes, una cuenta Pro 3000 minutos al mes. Y si tienes cuentas pagadas, puedes obtener diferentes niveles y también puedes pagar por ellos. Y así se proporciona una integración continua que se define utilizando código. Y estas acciones de GitHub se definen utilizando archivos YAML que se guardan en el repositorio. Por lo tanto, se encontrarán en el directorio de GitHub dentro de una carpeta llamada flujos de trabajo. Y luego puedes crear varios archivos YAML para cada flujo de trabajo que quieras definir. Por lo tanto, se confirman. Se versionan, puedes hacer solicitudes de extracción, verificar y revisar que se vean bien. Y sinceramente, en comparación con el uso de un sistema como Travis CI o CircleCI, este enfoque no va a ser muy diferente. Sin embargo, algo bueno es que no tienes que crear una nueva cuenta. No tienes que autorizarlo, configurarlo y todas esas cosas. Ya que todo está bajo el techo de GitHub, todo funciona junto de manera bastante fluida.
Una buena cualidad de estos flujos de trabajo es que son componibles. Por lo tanto, un flujo de trabajo está compuesto por uno o más trabajos y luego un trabajo está compuesto por uno o más pasos. Estos diferentes trabajos se ejecutan en diferentes máquinas virtuales. Puedes especificar dependencias. Puedes decir que este trabajo depende de ese otro trabajo. Y al definirlos de esa manera, puedes construir algún tipo de gráfico de dependencia y ejecutar código en paralelo. Y los pasos individuales se ejecutan secuencialmente. Por lo tanto, los pasos pueden hacer referencia a repositorios externos de GitHub. Y por ejemplo, esta línea que se usa aquí, representa código que verías dentro de uno de estos archivos de flujo de trabajo. Y esto significa que se está utilizando
2. GitHub Actions y Ejemplo de Flujo de Trabajo
Short description:
Y eso en realidad se traduce en un repositorio de GitHub. Otra cosa que puedes hacer es definir la configuración utilizada por estos flujos de trabajo. Es una forma de establecer pares clave-valor que puedes usar dentro de tus flujos de trabajo. Si adoptas las Acciones de GitHub, considera crear acciones para patrones de organización comunes. Veamos un ejemplo de flujo de trabajo para una solicitud de extracción. La salida de estos flujos de trabajo es contextual dentro de la solicitud de extracción. Ahora, veamos un archivo de flujo de trabajo. Representa el esqueleto necesario para diferentes flujos de trabajo. Tenemos un flujo de trabajo llamado PR lint test.yaml. Especifica el disparador para ejecutar este flujo de trabajo. Tenemos una cláusula de trabajos con un trabajo de construcción definido.
acciones slash set up dash node en V2.1.4. Y eso en realidad se traduce en un repositorio de GitHub. En este caso, es la organización de acciones, que es mantenida por GitHub, y luego el repositorio de configuración de node y eso. Y luego ese símbolo de arroba allí, eso hace referencia a una etiqueta. Y esto significa que queremos usar la etiqueta V2.1.4.
Otra cosa que puedes hacer es definir la configuración utilizada por estos flujos de trabajo. Y esa configuración termina en la configuración del proyecto. Y esa configuración se llama un secreto. Esos secretos se mantienen ocultos a los ojos de aquellos que no deberían verlo necesariamente. Pero en esencia, es una forma de establecer pares clave-valor que puedes usar dentro de tus flujos de trabajo.
Otra cosa que debes considerar hacer si adoptas las GitHub Actions es crear acciones para patrones de organización comunes. Por ejemplo, si tu empresa tiene tal vez una docena de repositorios de node, y todos terminan implementando microservicios dentro de tu infraestructura, tendría sentido crear GitHub Actions que luego puedas compartir entre todos esos proyectos.
Muy bien, ahora veamos un ejemplo de flujo de trabajo, este es uno que vamos a usar para una solicitud de extracción. Y al igual que otras soluciones de CI, si las has usado, es que la salida de estos termina siendo contextual dentro de la solicitud de extracción. En este caso, podemos ver que hay una solicitud de extracción mal elaborada sin descripción. Pero podemos ver en la parte inferior que se han publicado los resultados del flujo de trabajo. Por lo que son muy convenientes para ver contextualmente dentro de una solicitud de extracción.
Así que veamos un archivo de flujo de trabajo. Esto representa un poco de esqueleto, que necesitarás usar en estos diferentes flujos de trabajo. Pero no es tan malo. En este caso, tenemos un flujo de trabajo llamado PR lint test.yaml. Lo primero que hacemos es definir un nombre. Esto se mostrará en la interfaz de usuario de GitHub. En este caso, el nombre es linter y prueba de aceptación. Luego tenemos esta cláusula on aquí, que especifica esencialmente el disparador para ejecutar este flujo de trabajo. Y lo que esto dice es que cuando se hace una solicitud de extracción contra la rama principal, se debe iniciar este flujo de trabajo. También se observa ese campo colgante llamado workflow dispatch. Y al proporcionarlo, puedes activar manualmente este flujo de trabajo también utilizando la interfaz de usuario. Después de eso, tenemos esta cláusula de trabajos. Y dentro de ella tenemos un trabajo de construcción definido.
3. Running Steps in a Workflow
Short description:
El código se verifica usando la acción de verificación. El entorno de node se configura usando la acción de configuración de node, proporcionando la última versión LTS. Las dependencias se instalan usando npm install. Se ejecuta el linter asumiendo que se ha definido un script de lint. Se construye y se inicia un contenedor Docker usando el comando Docker compose.
Aquí estamos diciendo que los trabajos se ejecutarán en la última imagen de Ubuntu. Por lo tanto, estos terminan viviendo dentro de una máquina virtual. Por lo tanto, esto se ejecutará dentro de una máquina virtual con Ubuntu instalado. Por lo tanto, ese paso de construcción o trabajo está compuesto por pasos individuales. Y el primer paso aquí es que el código se verifica. Por lo tanto, muchos de los flujos de trabajo que escribirás probablemente comenzarán con este paso para verificar el código. Aunque no necesariamente todos ellos. En este caso, estamos usando la acción de verificación en la organización oficial de acciones, y estamos usando la etiqueta flotante llamada v2.
Bien, aquí también hay algunos pasos adicionales. Lo primero que queremos hacer es configurar el entorno de node. Y para ello, utilizamos otra acción de GitHub llamada configuración de node. Y luego puedes ver que tenemos una propiedad adicional aquí llamada width. Esa es una forma en la que podemos proporcionar argumentos a estos pasos. En este caso, hay un argumento que ese paso acepta llamado versión de node. Y como podrás haber adivinado, eso representa la versión de node que queremos instalar, en este caso, la última LTS. Esta acción proporciona el binario de node, probablemente también proporciona npm, yarn y algunas otras comodidades que probablemente sean aplicables a una aplicación de node. Después de eso, vamos a instalar las dependencias. Y para ello, ejecutaremos npm install. En este caso, no hay una cláusula uses, solo se utiliza la cláusula run. Y lo que eso significa es que no necesitamos usar una dependencia de acción externa para esto, en su lugar, simplemente ejecutamos el siguiente comando de shell. Y nuevamente, vamos a seguir un patrón similar con el linter. Y así es como ejecutamos un linter, esto asume que ya tenemos un script de lint definido en nuestro archivo package.json. En la parte inferior, puedes ver una captura de pantalla de este paso. Y así es como se ejecutan cada uno de los pasos, y puedes ver la salida, y luego puedes expandirlos. Aquí vemos que el proceso de linting tardó aproximadamente un segundo, y podemos ver la salida del comando. Y así es como se muestra la salida estándar y el error estándar para que puedas verlo y luego depurar la acción fallida. Aquí hay otro que probablemente sea aplicable a muchos proyectos. Y esto es, veamos, construir un contenedor Docker. Y así es como se llama el paso, construir y iniciar contenedores Docker. Y se utiliza el comando Docker compose. Y así es como funcionan las máquinas virtuales de flujo de trabajo de GitHub.
4. Running Docker Compose and Deploying Containers
Short description:
Ejecutamos Docker Compose para ejecutar los contenedores Docker en segundo plano. Especificamos el entorno para ejecutar las pruebas MPM. El archivo YAML de Docker Compose está configurado para escuchar en el puerto 1337. Proporcionamos el nombre de host y el puerto a la suite de pruebas. Una captura de pantalla muestra que se aprobaron 110 pruebas. Se desencadena otro flujo de trabajo cuando la solicitud de extracción se fusiona en la rama principal. El archivo de flujo de trabajo se llama main deploy.yaml. Configura el entorno de Docker, construye y envía el contenedor al registro.
GitHub Actions proporciona solo un conjunto de herramientas convenientes, una de ellas es Docker. Y aquí, ejecutamos Docker Compose, haciendo referencia al archivo YAML de Docker Compose, que está incluido en el proyecto. Y así decimos que queremos que los contenedores Docker se ejecuten y luego el indicador -d indica que queremos que se demonice y se ejecute en segundo plano. Una vez que los contenedores se ejecutan, pasan a segundo plano y el siguiente paso continúa. En este caso, para ejecutar las pruebas MPM, especificamos un entorno para la aplicación. Y así, el archivo YAML de Docker Compose se ha configurado para escuchar en el puerto 1337. Y luego proporcionamos ese nombre de host y puerto a esta suite de pruebas en particular. En la parte inferior hay una captura de pantalla del paso. Una vez que se completa, podemos ver que se aprobaron 110 pruebas en un segundo. Y si, y si desplazamos hacia arriba, veríamos la salida de cada prueba individual. Así es como se ve la salida completa del flujo de trabajo. Dentro de una solicitud de extracción, puedes hacer clic para obtener más información. Aquí vemos que tenemos el flujo de trabajo de linter y pruebas de aceptación. Se ha seleccionado el trabajo de construcción y luego se muestran cada uno de los pasos individuales a la derecha. Bien, ahora veamos otro flujo de trabajo. Este es un flujo de trabajo que representa cuando nuestro código, cuando nuestra solicitud de extracción se fusiona en la rama principal. Nuevamente, tenemos un poco de plantilla. En este caso, tenemos un nuevo archivo de flujo de trabajo. Este se llama main deploy.yaml. Nuevamente, tiene un nombre, en este caso, desplegado a producción. El campo on es un poco diferente. Y así, esto indica que cuando se realiza un push a la rama principal, es cuando queremos desencadenar este flujo de trabajo. Y nuevamente, tengo el campo de envío de flujo de trabajo aquí, para que podamos ejecutar el código manualmente. Bien, y aquí en los trabajos, primero tenemos un trabajo de construcción. Nuevamente, esto indica que se ejecutará en Ubuntu latest. Y el primer paso aquí nuevamente es revisar el código. Bien, ahora tenemos algunos pasos adicionales. Y así, aquí queremos configurar el entorno de Docker. Y para ello, estamos utilizando un repositorio proporcionado por la compañía Docker. Y luego queremos construir el contenedor y enviarlo al registro.
5. Configuration Setup and Deployment
Short description:
Esta parte cubre la configuración compleja para el contenedor Docker, incluyendo proporcionar el contexto, establecer la bandera de push y definir etiquetas. Las etiquetas incluyen una etiqueta específica para la construcción utilizando el nombre SHA del código. El trabajo de despliegue se define para ejecutarse después del trabajo de construcción y utiliza SSH para ejecutar comandos en un servidor remoto. Se utiliza un repositorio de acciones SSH de terceros para este proceso.
Y así estamos utilizando otro repositorio proporcionado por la compañía Docker. Este tiene una configuración más compleja. Y así, lo primero que estamos haciendo es proporcionar el contexto y que representa la ruta hasta el directorio raíz del sistema de archivos donde queremos que el contenedor Docker se construya. También tenemos esta bandera push true que indica que queremos enviarlo al servidor remoto. Y finalmente, tenemos algunas etiquetas definidas, por lo que esto utiliza una cadena YAML de varias líneas. Y así, estas etiquetas aquí, estos son los nombres completos y largos de las etiquetas. Pero estamos diciendo que la primera etiqueta es para registry.foo.com, barra x, barra y. Admitidamente, nombres de etiquetas horribles. Y luego finalmente, la parte más importante que viene después de los dos puntos. Así que estamos diciendo que cuando construyamos esto, queremos que sea la última etiqueta y también queremos especificar una etiqueta más específica para esta construcción en particular. En este caso, el nombre de la segunda etiqueta es sha, luego un guión, luego el nombre SHA real del código en el momento en que lo verificamos para ejecutar este código. Así que, nota cómo hay ese signo de dólar y luego las llaves dobles y luego github.sha. Así que esa sintaxis nos permite inyectar variables en estos scripts. Y así, hay un montón de variables diferentes que se pueden obtener de diferentes fuentes, pero una de ellas resulta ser el hash de github real. Así que eso se proporciona como github.sha. Al etiquetar esto como latest, podemos luego extraer esta imagen, referenciándola como latest, pero al etiquetarla también con un sha, podemos referirnos a ella más adelante y de alguna manera post mortem, referirnos a versiones anteriores.
Así que ahora veamos el despliegue real. Aquí tenemos un segundo trabajo definido para este flujo de trabajo, el nombre de este trabajo es despliegue. Y así, aquí tenemos el campo needs establecido en build. Lo que eso significa es que este trabajo de despliegue debe ejecutarse después de que se haya completado el trabajo de construcción. También especificamos que esto se ejecuta en Ubuntu latest nuevamente. Y aquí, solo tenemos un solo paso. Y así, este paso aquí es desplegar la aplicación en un VPS. Y así, esto va a representar una especie de proceso de despliegue de pobre hombre. Y así, este es bastante simple. Vamos a usar SSH para ejecutar algunos comandos en un servidor remoto. Pero por supuesto, podrías construir una integración más compleja usando algo como Kubernetes, por ejemplo. En este caso, estamos usando un paso de terceros. Esto es de alguien llamado Appleboy. Y luego estamos usando su repositorio de acciones SSH usando un
6. Configuración de Implementación y Despacho de Flujos de Trabajo
Short description:
Pasamos el host, el nombre de usuario y la clave de la colección de secretos. La configuración de conexión no se configura en el archivo YAML para evitar la inclusión de información confidencial. El script se ejecuta en el servidor remoto, descargando la imagen de Docker, deteniendo y eliminando la aplicación, y luego volviéndola a ejecutar. Los secretos se pueden inyectar como variables de entorno en el código de la aplicación. Puede haber un tiempo de inactividad cuando se detiene y se inicia la aplicación. Los flujos de trabajo se pueden despachar desde la pestaña Acciones si se define el campo en el archivo YAML.
nombre de etiqueta. Y luego esto acepta alguna configuración. Así que, estamos pasando el host, el nombre de usuario y la clave. Y así, estos terminan obteniendo los data de la colección de secretos para este proyecto. Y así, nuevamente, estamos usando las dobles llaves, pero esta vez, estamos usando secretos. y luego el nombre del secreto. Y así, para este proyecto, se definen tres secretos, SSH host, SSH user, SSH key. Y luego esos se obtienen y se pasan a este proyecto aquí. Y así, realmente no querrías configurar estos ajustes de conexión dentro de tu archivo YAML porque entonces tendrías que incluir potencialmente información confidencial en tu repositorio. Así que, aquí está la parte final de ese trabajo de implementación. Y así, aquí especificamos el script que se ejecutará en el servidor remoto. Entonces, lo que esto está diciendo es que lo primero que haremos en ese servidor es descargar la imagen de Docker del servidor, del registro remoto. Luego detendremos la aplicación, lo cual arrojaría un error normalmente si la aplicación no estuviera en ejecución. Así que, simplemente agregamos eso o true. También eliminamos la aplicación. Nuevamente, continuando si falla. Y finalmente, volvemos a ejecutar la aplicación. Y así, aquí estamos ejecutando docker run -D. Entonces, esto va a daemonizar el proceso para que se ejecute en segundo plano. De lo contrario, el comando se quedaría esperando. También vamos a pasar una variable de entorno. Esto muestra cómo puedes tomar algunos de estos secretos y luego inyectarlos en tu código de aplicación real. Entonces, en este caso, hay un secreto llamado some value. Y luego eso se asigna a una variable de entorno llamada some value y se pasa al contenedor. Aquí también se establece el nombre de la aplicación en to my app, que es la misma aplicación que habíamos detenido anteriormente. Y luego estamos especificando que estamos ejecutando la última versión de la aplicación. Y finalmente, estamos diciendo que dentro del contenedor, se ejecute el binario de node utilizando el punto de entrada específico.
Entonces, hay una pequeña limitación con este enfoque en el sentido de que, ya sabes, vas a tener algo de tiempo de inactividad al detener e iniciar la aplicación. Así que esto definitivamente no es algo que usarías necesariamente en producción, pero te dará una idea del poder que tienes disponible utilizando GitHub Actions. Mencioné anteriormente que los flujos de trabajo son despachables. Si tienes ese campo de despacho de flujo de trabajo disponible en tu archivo YAML. Y así, dentro del proyecto, si tienes eso definido,
7. Ejecución de GitHub Actions y Definición de Entradas
Short description:
Luego, aquí en el lado derecho, hay este menú desplegable Ejecutar Flujo de Trabajo. Puedes configurar el flujo de trabajo y ejecutar el código. Puedes definir entradas en el archivo YAML e ingresarlas en el menú desplegable para ejecutar el flujo de trabajo con el objetivo correcto. Las GitHub Actions se pueden definir utilizando node. La organización oficial de GitHub Actions proporciona un repositorio de ejemplo llamado Hello World JavaScript Action. Necesita un archivo llamado Action.yaml, que describe la acción, especifica las entradas y salidas, y define el entorno en el que se ejecuta.
puedes ir a la pestaña Acciones. Luego, aquí en el lado derecho, hay este menú desplegable Ejecutar Flujo de Trabajo. Entonces puedes hacer clic en eso, puedes configurar el flujo de trabajo y luego hacer clic en Ejecutar Flujo de Trabajo, y se ejecutará el código. Por defecto, te permite seleccionar la rama, pero en realidad puedes configurar el archivo YAML para tener otras entradas también. Por ejemplo, tal vez quieras, tal vez tengas un flujo de trabajo que represente una implementación. Entonces podrías, por ejemplo, definir un objetivo para la implementación, como tal vez quieras implementar en producción versus en entorno de pruebas. Y así podrías definir esas entradas en tu archivo YAML. Y luego aquí dentro de este menú desplegable, podrías ingresar esas entradas y luego hacer clic en Ejecutar Flujo de Trabajo para ejecutar el código con el objetivo correcto en mente.
Muy bien, finalmente, echemos un vistazo a algunas de estas GitHub Actions. Y así como un pequeño bono, estas GitHub Actions pueden ser definidas utilizando node. Y así, la organización oficial de GitHub Actions nos proporciona un repositorio de ejemplo que vamos a ver ahora. Y el nombre de este repositorio es Hello World JavaScript Action. Y así, tomé el código de eso para esta presentación, pero luego lo limpié un poco para que encajara en las diapositivas. Así que esto no es exactamente lo que encontrarías dentro del repositorio. Entonces, el repositorio de GitHub Actions necesita algunas cosas. Una de ellas es un archivo llamado Action.yaml. Dentro de este archivo, primero se describe la acción. Aquí tenemos un nombre y una descripción para la acción. También puedes especificar las entradas. Y así, estas se correlacionan con las entradas en ese archivo YAML. Y así, aquí estamos diciendo que hay una sola entrada definida llamada whom. Y luego la descripción de whom es a quién saludar. Esta entrada no es obligatoria. Así que se establece en falso. Y luego se proporciona un valor predeterminado de world. También podemos especificar salidas. Y así, en este caso, tenemos una sola salida definida llamada time. Y así, ese campo de tiempo representará el tiempo en que se ejecuta este código. Puedes usar estas entradas y salidas para encadenar valores entre estos diferentes pasos dentro de tu proceso de compilación.
8. Uso de Valores en GitHub Actions
Short description:
Esta parte explica cómo usar valores en GitHub Actions. El código en index.js obtiene los valores de entrada, los registra, genera la hora actual y los asigna a una salida. El bloque catch maneja los errores y permite que la tarea falle. El archivo de flujo de trabajo de ejemplo incluye un trabajo de hola mundo que ejecuta la acción de hola mundo utilizando un repositorio de GitHub.
Y finalmente, estamos indicando el entorno en el que se ejecuta esto. Por lo tanto, esto se ejecutará en utilizando node 12. Y el punto de entrada será index.js. Así es como se ve index.js. Para esto, se requieren dos paquetes. Ambos son proporcionados por la organización NPM, add actions. Entonces, el primero es core. Y el segundo es GitHub. Estos nos permiten interactuar con la API de GitHub actions de una manera conveniente. El código aquí está envuelto en un bloque try catch. Entonces, lo primero que haremos es obtener uno de los valores de entrada. Aquí estamos obteniendo core.getInput. Buscaremos el valor de `whom`. Y luego asignaremos eso a una variable llamada name to greet. Y luego simplemente lo registraremos. Llamaremos a console.log con ese valor. Y luego la salida que imprimimos en el registro se muestra en la salida de la acción. Después de eso, simplemente generaremos la hora actual, y luego la asignaremos a una salida. Así que core.setOutput, pasando el nombre y el valor. Ahora también hay un montón de data disponible en GitHub.context.payload, que representa la acción que se está ejecutando. En este caso, en realidad no estamos haciendo nada con eso. Pero ten en cuenta que está ahí. Y finalmente, envolvemos todo con este catch. Y así capturamos el error. Y luego llamamos a core.setFailed, pasando el mensaje de error en caso de fallo. Y así podemos hacer que toda la tarea falle y proporcionar información al usuario también. Y así es como puedes usar realmente estos valores.
Y esto representa una versión truncada de uno de estos archivos de flujo de trabajo. Aquí tenemos este paso de hola mundo, o perdón, el trabajo se llama hola mundo. Y luego el primer paso aquí ejecuta esa acción de hola mundo. Así que aquí podemos ver que estamos usando ese GitHub
9. Uso del paso 'hello' y resultados de la encuesta
Short description:
Estamos utilizando el campo de nombre para especificar el paso como 'hello' y proporcionando el valor 'whom'. Luego tenemos otro paso que muestra la salida, demostrando cómo usar el valor. Llamamos a steps.hello.outputs.time para acceder a la variable del paso anterior. Gracias por ver, sígueme en Twitter en TLHunter. El ganador más grande en la encuesta es la integración de repositorio, con un 40% eligiendo GitHub Actions y GitLab. Es un poco sorprendente, ya que esperaba más herramientas de terceros dedicadas. Pero cada vez más empresas están utilizando GitHub Actions o GitLab por la conveniencia de la integración con su sistema git.
repo. Estamos utilizando este campo de nombre que indica que este paso se llamará hello. Y luego también estamos usando esto con cosas que podemos proporcionar, el valor whom. Y luego, después de eso, tenemos otro paso que se ejecuta. El segundo paso simplemente muestra la salida, mostrando cómo se puede usar ese valor. Aquí estamos llamando steps.hello.outputs.time. Y podemos usar esa variable que habíamos mostrado en el paso anterior. Bueno, eso es todo. Gracias por ver. Siéntete libre de seguirme en Twitter en TLHunter. Y esta presentación también está disponible en línea. Así que Thomas, me gustaría invitarte a unirte a mí en el escenario para que podamos ver los resultados de tu encuesta. Hola, Thomas, gracias por unirte. Hola, gracias por tenerme. Muy bien. Veamos qué respondió la gente. El ganador más grande, un 40%, es la integración de repositorio. Así que GitHub Actions y GitLab. Y bueno, espero que esto no te sorprenda con tu charla. ¿Qué piensas? Sí, un poco sorprendente. Pensé que habría sido principalmente herramientas de terceros dedicadas. Sí. ¿Por qué crees? Bueno, eso es lo que la mayoría de mis empleadores anteriores habían utilizado. Oh, sí. Sí. Sí. Para mí, creo que en el pasado, generalmente era CircleCI o Travis o también Jenkins en gran medida, pero cada vez más veo empresas que utilizan GitHub Actions o GitLab simplemente porque está integrado en, bueno, como dijiste, en su sistema git, y eso es más conveniente, ¿verdad? Oh, sí. 100%, sí. Sí. Entonces, no quiero decir nada malo sobre estas otras soluciones, porque tienen excelentes productos también con diferentes valores, pero es más fácil ingresar si es el mismo IDE y no tiene
QnA
Q&A sobre anclas YAML, plataformas móviles y Jenkins
Short description:
La primera pregunta es sobre las anclas YAML y la reutilización de pasos/configuraciones en GitHub Actions. La segunda pregunta es sobre cómo mover GitHub Actions a otra plataforma y usarlo para repositorios autohospedados. La tercera pregunta es sobre el uso de GitHub Actions como alternativa para ejecutar un servidor Jenkins.
No tienes que preocuparte por la autenticación, ese tipo de cosas. Entonces, Thomas, vamos a entrar en la sesión de preguntas y respuestas. La primera pregunta de nuestra audiencia es de Lara M. Cuando investigué por última vez las GitHub Actions, no admitía anclas YAML en el flujo de trabajo. ¿Sigue siendo así? Y si es así, ¿cuál es la mejor manera de reutilizar estos pasos/configuraciones? De hecho, debo disculparme. No sé qué es una ancla YAML. De acuerdo. Entonces, Lara, si puedes proporcionar más información sobre lo que quieres decir, podemos volver a esta pregunta más adelante. La siguiente pregunta es de Dara Mohammad. ¿Qué tan sencillo es mover las GitHub Actions a otra plataforma como GitLab? Y además, ¿es posible usar GitHub Actions para un repositorio autohospedado? Sí, buena pregunta. Diré que mi empleador está considerando actualmente pasar de una de estas otras soluciones a GitHub Actions. Y hasta donde sé, no hay una forma fácil de automatizar eso. Alguien podría tener una solución que automatice el cambio de una a otra. Pero al final del día, sospecho que requerirá algo de trabajo manual. Incluso si rediseñas estos archivos YAML, sabes, generalmente habrá alguna referencia a algunas características específicas de la herramienta de CI. Y así, creo que, lamentablemente, es un proceso un poco manual. Pero, definitivamente, algo que vale la pena considerar. El precio es una cosa. Pero sí, la conveniencia de tener todo en un solo lugar sin duda ayudará a la productividad. Sí. Además, a ninguna de estas empresas le interesa proporcionar un script de exportación, ¿verdad? Por eso probablemente sea difícil automatizar esto. Solo sería para GitHub, sería conveniente tener un importador. Pero tal vez algún día. Tal vez algún día. O puedes escribirlo tú mismo, por supuesto. La siguiente pregunta es de PM Bonugul, ¿usar GitHub Actions es una alternativa para ejecutar mi propio servidor Jenkins? Sí, definitivamente es una alternativa para ejecutar tu propio servidor Jenkins. Supongo que hay algunas advertencias. Con Jenkins, puedes tener un poco más de control. Y así, puedes, ya sabes, ponerlo en una máquina de compilación realmente potente, o, ya sabes, incluso podrías ejecutar Jenkins en macOS, si lo estás utilizando para compilar aplicaciones de iOS, por ejemplo. Y luego, si estás utilizando una herramienta diferente como GitHub Actions, creo que admiten la capacidad de ejecutarlo en sistemas operativos que no sean Linux, pero probablemente tendrás que pagar un precio mucho más alto que si usas Jenkins autohospedado,
Instrumentando Internos de Node.js
Short description:
Puedes instrumentar los internos de Node.js, como los retrasos del bucle de eventos o la frecuencia de GC, para monitorear el rendimiento. Mide el retraso del bucle de eventos, el recuento de descriptores de archivos y el uso de memoria. Registra esta información para fallar una compilación o proporcionar un informe para la ejecución de CI.
por ejemplo. Sí. Muy bien. Pregunta de Alexi. ¿Puedes recomendar formas de instrumentar los internos de Node.js como los retrasos del bucle de eventos o la frecuencia de GC para enviar a los servicios? Absolutamente. De hecho, es una sección de mi libro, Sistemas Distribuidos con Node.js, que trata sobre la instrumentación de aplicaciones de Node. Pero supongo que, en relación con la integración continua, tal vez tengas una prueba que busca regresiones. Si estás ejecutando una aplicación, tal vez quieras asegurarte de que el rendimiento no esté disminuyendo. Y sí, para hacer eso, hay algunas formas de conectarse a los internos de Node. Así que puedes, sí, medir cosas como el retraso del bucle de eventos, el recuento de descriptores de archivos, el uso de memoria. Y luego podrías, ya sabes, registrar esa información en algún lugar donde luego podrías fallar una compilación, o al menos proporcionar un informe y la salida para la ejecución de CI. Sí, definitivamente es posible.
Compartir Caché y Despliegue con GitHub Actions
Short description:
Alguien preguntó si hay una forma de compartir caché entre los trabajos de solicitud de extracción y los trabajos de fusión. El orador mencionó que podría existir una acción de GitHub de terceros con este propósito, utilizando representaciones de la caché almacenadas en disco. Para el despliegue con GitHub Actions, el orador recomendó utilizar el método de despliegue que mejor se adapte a la configuración de la infraestructura, ya que GitHub Actions puede admitir diversas herramientas de despliegue.
De acuerdo, recibí comentarios de alguien de que el volumen está un poco bajo. ¿Puedes subirlo un poco? Sí, definitivamente. Genial. ¿Es eso mejor? Oh, bueno, ¿dónde está el volumen alto? No, está bien. Disculpa, una broma tonta. No pude resistirme. La siguiente pregunta es de Austin. ¿Hay alguna forma de compartir caché entre los trabajos de solicitud de extracción y los trabajos de fusión? Oh, sí, buena pregunta. Sí, compartir caché generalmente se refiere, por ejemplo, al directorio de módulos de Node. Y, sabes, de memoria, no se me ocurre una forma fácil de hacerlo, pero no me sorprendería que alguien más haya creado, como, una acción de terceros que permita, ya sabes, tomar alguna especie de representación de lo que estaría en disco. Por ejemplo, con los módulos de Node, una forma de representarlo sería hashear el archivo package-lock.json. Y luego podrías hashear eso y comprimir los módulos de Node. Luego podrías escribir ese archivo tarball en, por ejemplo, Amazon S3. Y luego en una ejecución diferente, podrías tener otra acción que verifique S3 antes de ejecutar la instalación de NPM y luego, de alguna manera, descargarlo según ese hash. Y si está allí, entonces descargas el archivo. Si no, realizarías una instalación de NPM. Así que no me sorprendería si alguien tiene una acción de GitHub de terceros solo para eso.
De acuerdo. Entonces, si alguien sabe algo al respecto, háganoslo saber en el canal de Discord si está disponible para que podamos ayudar. Tenemos tiempo para una pregunta más. Y es de Martin. ¿Qué método de despliegue recomiendas con GitHub Actions? ¿Qué método de despliegue? Bueno, en realidad, eso depende de, ya sabes, cómo se configure tu infraestructura. Entonces, ya sabes, con estas herramientas de CI, son bastante independientes de tu proceso de despliegue, por lo que si estás desplegando en Heroku o, ya sabes, Kubernetes, o tal vez solo estás haciendo SSH en una máquina remota, aún puedes utilizar cualquiera de esas herramientas de despliegue con GitHub Actions. Y así, tengo, como, un proyecto paralelo que construirá un archivo, enviará una imagen a un contenedor Docker remoto y luego, ya sabes, instruirá a Kubernetes para que descargue esa imagen y vuelva a ejecutar la aplicación. Entonces, ya sabes, no recomendaría en realidad ningún enfoque de despliegue en particular, pero diría que con GitHub Actions, realmente puedes admitir muchas herramientas de despliegue diferentes. Lo que mejor se adapte a tus necesidades. Sí. Como dije, no tenemos más tiempo. Hemos recibido un...
Preguntas y respuestas sobre anclajes YAML, depuración y compartición de caché
Short description:
Recibimos preguntas sobre anclajes YAML, depuración en acciones y compartición de caché entre trabajos de solicitud de extracción y fusión. El ganador del libro será contactado a través de Discord y el libro se enviará directamente a ellos. ¡Gracias, Thomas, por unirte a nosotros!
Voy a leer las preguntas para que puedas evaluarlas para tu sorteo de libros. Recibimos una respuesta de Lara, quien preguntaba sobre... Solo veo su respuesta ahora... sobre anclajes YAML, y ella respondió que los anclajes YAML te permiten hacer referencia a data para no tener que repetirlo varias veces, manteniendo la configuración más seca. Así que eso se relaciona con la pregunta que acabamos de tener, ¿verdad? Entonces, ¿hay alguna forma de compartir caché entre trabajos de solicitud de extracción y fusión? Esperemos que los anclajes YAML puedan ayudar con eso. Otra pregunta es de AMP. Estoy teniendo problemas para depurar algo en acciones. ¿Alguna sugerencia? He configurado un entorno local con Docker Compose y todo está bien. Pero luego, cuando lo ejecuto en acciones, obtengo un error. Y otra pregunta es de D. Nekto's act es increíble. Solía hacer mi- Oh espera, esto no es una pregunta, es solo un comentario sobre otra persona. Así que eso es todo el tiempo que tenemos. Entonces, ¿puedes informarnos primero cómo el ganador recibirá su libro? Y luego haré un redoble de tambores y anunciaremos al ganador. Sí, definitivamente. Contactaré al ganador directamente a través de Discord, obtendré su dirección de correo electrónico, y se la proporcionaré al editor para que puedan enviarlo directamente a él. Oh, genial. De acuerdo. Así que, todos, contengan la respiración, es hora del redoble de tambores. Genial. Sí, me gusta mucho la pregunta sobre la caché. Es interesante y no había pensado personalmente en eso con GitHub hasta ahora, pero lo he usado en soluciones anteriores. Así que me gusta esa pregunta. La pregunta es, ¿hay alguna forma de compartir caché entre trabajos de solicitud de extracción y trabajos de fusión? Genial. Entonces, Aston es el que pregunta. No sé si esa es una palabra, pero es el que hace la pregunta. Y Thomas se pondrá en contacto contigo y recibirás este bonito libro. Asegúrate de informarnos en Twitter cuando lo recibas. Sería genial tener una bonita foto. Y también etiqueta a Thomas, por supuesto. Y hazle saber qué te pareció el libro cuando termines de leerlo. Thomas, muchas gracias por unirte a nosotros. Ha sido un placer tenerte de nuevo, y esperamos verte de nuevo pronto. Genial. Gracias por tenerme.
