En el primer artículo de esta serie te conté que el marketplace de GitHub pone a tu disposición más de 3.500 acciones listas para usar. Sin embargo, es posible que necesites llevar a cabo alguna tarea que no esté disponible. Hoy quiero contarte cómo crear tus propias acciones para GitHub Actions.
Cómo crear una acción
A día de hoy es posible crear tus propias tareas utilizando JavaScript o Docker. Para este artículo voy a crear una acción utilizando un contenedor de Docker que lanza Apache Benchmark como tarea, pasándole a este una serie de parámetros. Para poder crear esta acción necesitas mínimo estos tres archivos:
action.yml
Toda acción necesita un manifiesto donde se definen los siguientes valores:
name: Apache Benchmark Action
description: Benchmark your app
author: Gisela Torres
inputs:
URL:
description: "The URL you want to test"
required: true
Concurrency:
description: "The number of concurrent users for the test"
required: false
default: '50'
NumberOfRequests:
description: "Number of request the test will launch"
required: false
default: '1000'
runs:
using: "docker"
image: "Dockerfile"
branding:
icon: "activity"
color: "orange"
Como puedes ver, en él se deben indicar:
- name (obligatorio): se trata del nombre de tu acción.
- description (obligatorio): texto descriptivo de para qué sirve.
- author (opcional): no está de más indicar quién es el que ha parido esta acción 😀
- inputs (opcional): se trata de los parámetros de entrada que puede aceptar tu acción. En este caso puedes ver que acepta tres parámetros: URL, la cual es obligatoria, Concurrency, que nos permite indicar cuántos usuarios concurrentes queremos que se simulen en nuestra prueba, y NumberOfRequests con el número de peticiones. Estos dos últimos no son obligatorios y tienen un valor por defecto, en el caso de que no se establezcan en el workflow.
- runs: se utiliza para saber qué comando y archivo, en este caso, se debe utilizar para ejecutar esta acción. En este ejemplo estoy utilizando un archivo Dockerfile en el propio repositorio, pero también es posible utilizar una imagen pública.
- branding: este apartado es simplemente por si posteriormente quieres deplegar tu acción en el marketplace de GitHub. En él puedes elegir un icono, entre los que ofrece Feather Icons, y un color de fondo.
Dockerfile
Tal y como he especificado en el manifiesto, necesito un archivo Dockerfile que defina cómo será mi contenedor:
FROM debian:10.3-slim
LABEL maintainer="Gisela Torres"
ADD entrypoint.sh /entrypoint.sh
RUN apt-get update && apt-get install -y apache2-utils
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
Como puedes ver, utilizo una imagen de debian como base e instalo apache2-utils, que me permitirá usar Apache Benchmark. Por último, como punto de entrada, añado un archivo externo, al cual doy permiso de ejecución, llamado entrypoint.sh.
entrypoint.sh
En este archivo es donde voy a recuperar los parámetros definidos en el manifiesto y ejecutar mi prueba de carga. Date cuenta de que las variables de entorno que se crean a partir de los inputs tienen el prefijo INPUT_ y están en mayúsculas.
#!/bin/sh -l
sh -c "echo Entry point..."
sh -c "echo URL: $INPUT_URL"
sh -c "echo Concurrency: $INPUT_CONCURRENCY"
sh -c "echo Number of requests: $INPUT_NUMBEROFREQUESTS"
sh -c "ab -n $INPUT_NUMBEROFREQUESTS -c $INPUT_CONCURRENCY $INPUT_URL"
Como ves, el script es súper sencillo: muestro el valor de todas las variables de entorno, generadas a partir de los inputs definidos, y por último ejecuto el comando ab con el valor de estas.
Cómo probar tu acción
Con estos tres archivos ya tienes tu acción lista para ser usada. Ya solo necesitas crear un workflow dentro del mismo repositorio:

Para que tu flujo reconozca la acción, debe hacer referencia al directorio donde está ubicada en la propiedad uses:
name: Testing ab-action
on: push
jobs:
benchmarking:
name: Test my site
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: ./ab-action
with:
URL: "YOUR_URL"
Como puedes ver, he creado un workflow que se ejecuta con cada push que ocurre en el repositorio, donde solamente se ha definido un job con dos tareas: la primera de ellas es para conseguir una copia del código y la segunda es la que utiliza nuestra acción ubicada en el directorio ab-action. En el apartado with es donde establecemos el valor de los parámetros (inputs) que se definieron. Si recuerdas, dos de los cuales no eran obligatorios y se había establecido un valor por defecto para estos. Es por ello que sólo es necesario pasar la URL sobre la que quiere lanzar el test.
Una vez aplicados los cambios en GitHub puedes ver en el apartado Actions el resultado:

¡Saludos!

Bootcamp DevOps
Si tienes ganas de meterte en el área de DevOps, formo parte del
equipo de docentes del Bootcamp DevOps Lemoncode, ¿Te animas a
aprender con nosotros?