En mayo de 2019, GitHub anunció el lanzamiento del servicio Package Registry. Después de esto, ya en agosto, se anunció el soporte para CI / CD en Actions.
En el artículo, le diré qué tipo de servicios son y cómo se pueden usar en el ejemplo de un pequeño proyecto para mascotas en GitHub.
¿Qué tipo de servicios son estos?
GitHub Actions es una plataforma que le permite administrar el ciclo de vida del software, cuyo código fuente está alojado en GitHub. De hecho, TravisCI, CircleCI y muchas otras plataformas de CI / CD gratuitas recibieron un nuevo competidor en la persona de Actions.
El Registro de paquetes de GitHub es el repositorio central de artefactos; actualmente hay cinco tipos diferentes de artefactos compatibles.
Tipos de artefactos admitidos en acciones
Esta es una oportunidad conveniente para tener todos los artefactos en un solo lugar, ya que no siempre es recomendable implementar su servidor Nexus o Artifactory.
GitHub se está volviendo cada vez más similar a GitLab, y en algún lugar ya ha superado a un oponente, por ejemplo, GitLab aún no admite paquetes NuGet y gemas Ruby. De hecho, si antes para proyectos de código abierto tenía que conectar integraciones externas a GitHub, ahora todos los huevos están en una sola canasta. Aquí dejemos que todos decidan si es bueno o malo, pero al menos es conveniente.
¿Cómo intentarlo?
Ambos servicios están actualmente en modo beta, puede registrarse para una prueba beta en estas páginas .
La migración desde otros servicios es muy simple, migré varios de mis proyectos favoritos de TravisCI y DockerHub a Actions and Package Registry respectivamente.
Te mostraré cómo se ve en un ejemplo. El proyecto es el más común, escribí sobre él en este artículo. Nada complicado, el código LaTeX habitual, con la ayuda de los cuales se recopilan los artefactos (2 archivos PDF), se publican en las versiones de GitHub. Para no descargar un montón de paquetes LaTeX, escribí un Dockerfile para que pueda trabajar cómodamente desde cualquier sistema operativo.
Registro del paquete
Para comenzar a trabajar con Package Registry en lugar de DockerHub, debe seguir solo dos pasos simples.
Creamos un token en la configuración de GitHub (el token debe tener derechos para escribir y leer artefactos).
Página de creación de tokens
Y luego podemos autenticarnos con el token creado y los artefactos push, así de simple es:
docker login docker.pkg.github.com --username amet13 docker tag docker-latex:0.0.1 docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1 docker push docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1
Tenga en cuenta que indiqué específicamente mi apodo en GitHub en minúsculas, de lo contrario recibirá un error de Docker:
Error parsing reference: "docker.pkg.github.com/Amet13/master-thesis/docker-latex:0.0.1" is not a valid repository/tag: invalid reference format: repository name must be lowercase
Así es como se ve en la interfaz web de GitHub:
Página de registro de paquetes para imágenes de Docker
Además de las instrucciones para descargar la última imagen, hay estadísticas de descarga disponibles, la capacidad de descargar una capa de Docker por separado a través de la interfaz web, el historial de descargas de imágenes está disponible.
Acciones
Las acciones son un poco más complicadas, pero para aquellos que alguna vez han trabajado con cualquier otro sistema de CI / CD, no será difícil de entender. La configuración en Actions se describe mediante YAML declarativo, aunque antes se usaba HCL.
Algunos conceptos básicos (no traduciré intencionalmente las definiciones, creo que todo está claro aquí):
- Flujo de trabajo: un proceso que administra el ciclo de vida del software (compilación, prueba, paquete, lanzamiento, implementación) para el repositorio
- Archivo de flujo de trabajo: el archivo en el que se describe el flujo de trabajo, se encuentra en la raíz del repositorio en el directorio
.github/workflows/ - El trabajo es cada ejecución del flujo de trabajo, el trabajo se activa, en un punto en el tiempo se puede iniciar mucho trabajo
- Paso: cada trabajo tiene un paso, en cada paso puede ejecutar comandos o acciones
- Acción: un "complemento" escrito por alguien; se puede encontrar una lista de muchas acciones en el repositorio de acciones increíbles
- Entorno virtual: el entorno en el que se ejecuta Job (de hecho, es una máquina virtual en Windows, macOS o Linux)
- Runner es un entorno implementado para iniciar un trabajo, solo un trabajo puede ejecutarse en Runner a la vez
- Evento: un evento que activa el flujo de trabajo, por ejemplo, Push, Pull Request, Webhook, Cron Job, etc.
- Artefacto: artefactos (binarios, imágenes, registros, etc.)
Así es como se ve la página de la lista de trabajos en Workflow.
Limitaciones y prohibiciones:
- 20 flujos de trabajo por repositorio
- 1000 solicitudes de API por hora para todas las acciones en el repositorio
- tiempo de trabajo máximo: 6 horas
- 20 trabajos pueden trabajar en paralelo en el repositorio (para todos los flujos de trabajo)
- está prohibido utilizar acciones para la minería de criptomonedas y la informática sin servidor
La documentación más actualizada está disponible en este enlace .
Y aquí están los registros de uno de los Job
Ejemplo
Volvamos al ejemplo, así es como se ve mi configuración, la analizaremos con más detalle en partes.
Especifique un nombre para Flujo de trabajo y describa en qué disparador debe activarse (en la documentación se describe una lista de todos los disparadores):
name: master-thesis on: [push]
En qué entorno virtual ejecuta Job:
jobs: build: # ubuntu-latest, ubuntu-18.04, or ubuntu-16.04 # windows-latest, windows-2019, or windows-2016 # macOS-latest or macOS-10.14 runs-on: ubuntu-latest
El primer paso, en name: especifique el nombre del Paso (opcional), y en uses: qué Acción queremos usar, en este caso, clone el repositorio:
steps: - name: Checkout repo uses: actions/checkout@v1
En el siguiente paso, no usamos Action, sino solo un conjunto de nuestros comandos donde iniciamos sesión en el Registry Package, recopilamos la imagen de Docker y la enviamos al repositorio de imágenes. En el bloque env: establecemos variables de entorno, tomamos una de ellas de los secretos:
- name: Build docker image and push it to the registry env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} DOCKER_IMAGE_ORIGIN: "docker.pkg.github.com/amet13/master-thesis/docker-latex" run: | # Pull submodules git submodule init git submodule update --remote # Login to GitHub Packages and build Docker image docker login docker.pkg.github.com -u amet13 -p ${GITHUB_TOKEN} docker pull ${DOCKER_IMAGE_ORIGIN}:latest docker build -t ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} . # Generate PDF artifacts docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "latexmk -xelatex -synctex=1 -jobname=master-thesis main.tex" docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "cd presentation/ && latexmk -xelatex -synctex=1 -jobname=presentation main.tex" # Publish Docker image to GitHub Packages (with latest tag) docker tag ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} ${DOCKER_IMAGE_ORIGIN}:latest docker push ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} docker push ${DOCKER_IMAGE_ORIGIN}:latest
Estoy seguro de que en un futuro próximo aparecerá una Acción que etiquetará y empujará automáticamente las imágenes en lugar de escribir manualmente los comandos de Docker.
Agregar un secreto que contiene un token github
El siguiente paso después de crear los PDF es crear una versión en GitHub e incluir los artefactos recopilados en esta versión. Para crear automáticamente una versión, utilizamos una Acción de terceros , en la que en el bloque if: puede especificar la condición para iniciar el paso, solo al crear la etiqueta:
- name: Create GitHub release with artifacts uses: softprops/action-gh-release@v1 if: startsWith(github.ref, 'refs/tags/') with: files: | master-thesis.pdf presentation/presentation.pdf name: "Build ${GITHUB_SHA}" env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
Resumen
A pesar del estado beta, ambos servicios funcionan bien, estoy seguro de que muchas cosas estarán terminadas.
En algunos puntos puede ser inconveniente, no hay variables globales, pero esto se puede hacer con muletas .
Me gustó el enfoque de GitHub para abandonar HCL en favor de YAML. También me gustó el soporte para muchos tipos de hosts, que son límites muy moderados (por ahora), veamos cómo funciona. En general, para canalizaciones simples en repositorios públicos en GitHub, tal grupo funcionará muy bien.
La traducción de este artículo ya está en medio .