A menudo tengo que crear una canalización para crear proyectos en Java. A veces es de código abierto, a veces no. Recientemente decidí intentar mover algunos de mis repositorios de Travis-CI y TeamCity a GitHub Actions, y esto es lo que resultó.
¿Qué automatizaremos?
Primero, necesitamos un proyecto que automatizaremos, hagamos una pequeña aplicación en Spring boot/Java 11/Maven. Para los propósitos de este artículo, no nos interesará en absoluto la lógica de la aplicación; la infraestructura alrededor de la aplicación es importante para nosotros, por lo que un simple controlador API REST será suficiente para nosotros.
Puedes ver las fuentes aquí: Todas las etapas de la construcción de una canalización se reflejan en las solicitudes de extracción de este proyecto.
JIRA y planificación
Vale la pena decir que normalmente usamos JIRA como rastreador de problemas, así que creemos un tablero separado para este proyecto y agreguemos los primeros problemas allí:
Un poco más adelante volveremos a las cosas interesantes que JIRA y GitHub pueden ofrecer en combinación.
Automatizamos el montaje del proyecto.
Nuestro proyecto de prueba se construye a través de maven, por lo que construirlo es bastante simple, todo lo que necesitamos es el paquete mvn clean.
Para hacer esto usando Github Actions, necesitaremos crear un archivo en el repositorio que describa nuestro flujo de trabajo, esto se puede hacer con un archivo yml normal, no puedo decir que me guste la "programación yml", pero ¿qué podemos hacer? lo hacemos en el directorio .github/ flowflow/ archivo build.yml en el que describiremos las acciones al construir la rama master:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean package -DskipTests
on — esta es una descripción del evento en el que se lanzará nuestro script.
en: pull_request/push — indica que este flujo de trabajo debe iniciarse cada vez que se realiza una inserción en el maestro y se crean solicitudes de extracción.
La siguiente es una descripción de las tareas (recibas nuevas vacantes en tu correo) y pasos de ejecución (pasos) para cada tarea.
se ejecuta en - aquí podemos seleccionar el sistema operativo de destino, sorprendentemente, incluso puedes elegir Mac OS, pero en repositorios privados esto es bastante caro (en comparación con Linux).
usos permite reutilizar otras acciones, por ejemplo, usando la acción action/setup-java instalamos el entorno para Java 11.
Por medio de podemos especificar los parámetros con los que lanzamos la acción, esencialmente estos son los argumentos que se pasarán a la acción.
Todo lo que queda es ejecutar la compilación del proyecto en Maven: run: mvn -B clean package bandera -B dice que necesitamos un modo no interactivo para que el experto de repente no quiera preguntarnos nada
¡Excelente! Ahora, cada vez que te comprometes con el maestro, comienza la construcción del proyecto.
Automatización de lanzamientos de pruebas
El montaje es bueno, pero en realidad un proyecto se puede montar de forma segura, pero no funcionar. Por tanto, el siguiente paso es automatizar las ejecuciones de prueba. Además, es muy conveniente ver los resultados de pasar las pruebas cuando realiza una revisión de relaciones públicas: sabe con seguridad que las pruebas pasan y nadie se olvidó de ejecutar su rama antes de realizar una fusión.
Realizaremos pruebas al crear una solicitud de extracción y la fusionaremos con la maestra, y al mismo tiempo agregaremos la creación de un informe sobre la cobertura del código.
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Verify
run: mvn -B clean verify
- name: Test Coverage
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
Para cubrir las pruebas, utilizo codecov junto con el complemento jacoco. codecov tiene su propia acción, pero necesita un token para funcionar con nuestra solicitud de extracción:
${{ secrets.CODECOV_TOKEN }} — veremos esta construcción más de una vez, secrets es un mecanismo para almacenar secretos en GitHub, podemos escribir allí contraseñas/tokens/hosts/urls y otros datos que no deberían incluirse en el código base del repositorio.
Puedes agregar una variable a los secretos en la configuración del repositorio en GitHub:
Puedes conseguir una ficha en Después de la autorización a través de GitHub, para agregar un proyecto público solo necesitas seguir un enlace como este: /[nombre del repositorio]. También se puede agregar un repositorio privado; para hacer esto, debe otorgar derechos de codecov a la aplicación en Github.
Agregue el complemento jacoco al archivo POM:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<!-- attached to Maven test phase -->
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<reportFormat>plain</reportFormat>
<includes>
<include>**/*Test*.java</include>
<include>**/*IT*.java</include>
</includes>
</configuration>
</plugin>
Ahora el bot codecov ingresará a cada una de nuestras solicitudes de extracción y agregará un gráfico de cambio de cobertura:
Agreguemos un analizador estático.
En la mayoría de mis proyectos de código abierto utilizo sonar cloud para el análisis de código estático, es bastante fácil conectarse a travis-ci. Por lo tanto, es un paso lógico al migrar a GitHub Actions hacer lo mismo. El mercado de acciones es algo genial, pero esta vez me decepcionó un poco, porque por costumbre encontré la acción que necesitaba y la agregué al flujo de trabajo. Pero resultó que el sonar no admite el trabajo mediante una acción para analizar proyectos en maven o gradle. Por supuesto, esto está escrito en la documentación, pero ¿quién lo lee?
No es posible mediante una acción, así que lo haremos mediante el complemento mvn:
name: SonarCloud
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Set up JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyze with SonarCloud
# set environment variables:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# run sonar maven plugin:
run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml
SONAR_TOKEN - se puede obtener en y necesitas registrarlo en secretos. GITHUB_TOKEN - este es un token integrado que genera GitHub, con la ayuda del cual sonarcloud[bot] podrá iniciar sesión en Git para dejarnos mensajes en las solicitudes de extracción.
Dsonar.projectKey — el nombre del proyecto en la sonda, puedes verlo en la configuración del proyecto.
Dsonar.organización — nombre de la organización de GitHub.
Hacemos una solicitud de extracción y esperamos a que aparezca sonarcloud[bot] en los comentarios:
Gestión de la liberación
Se configuró la compilación, se ejecutaron las pruebas y podemos realizar una versión. Veamos cómo GitHub Actions puede facilitar mucho la gestión de lanzamientos.
En el trabajo, tengo proyectos cuyo código base está en bitbucket (todo es como en esa historia “escribo en bitbucket durante el día, me comprometo con GitHub por la noche”). Lamentablemente, bitbucket no tiene herramientas de gestión de lanzamientos integradas. Esto es un problema, porque para cada lanzamiento tienes que crear manualmente una página en confluencia y colocar allí todas las funciones incluidas en el lanzamiento, buscar en los palacios de la mente, tareas en Jira, confirmaciones en el repositorio. Hay muchas posibilidades de cometer un error, puede olvidar algo o ingresar algo que ya se lanzó la última vez, a veces simplemente no está claro cómo clasificar una solicitud de extracción: si es una característica o una corrección de errores, o pruebas de edición, o algo infraestructural.
¿Cómo pueden ayudarnos las acciones de GitHub? Hay una gran acción: redactor de versiones, que le permite configurar una plantilla de archivo de notas de la versión para configurar categorías de solicitudes de extracción y agruparlas automáticamente en el archivo de notas de la versión:
Plantilla de ejemplo para configurar un informe (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' New Features'
labels:
- 'type:features'
# в эту категорию собираем все PR с меткой type:features
- title: ' Bugs Fixes'
labels:
- 'type:fix'
# аналогично для метки type:fix и т.д.
- title: ' Documentation'
labels:
- 'type:documentation'
- title: ' Configuration'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Changes
$CHANGES
Agregue un script para generar un borrador de versión (.github/workflows/release-draft.yml):
name: "Create draft release"
on:
push:
branches:
- master
jobs:
update_draft_release:
runs-on: ubuntu-18.04
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Todas las solicitudes de extracción a partir de ahora se recopilarán automáticamente en notas de la versión: ¡mágico!
Aquí puede surgir la pregunta: ¿qué pasa si los desarrolladores se olvidan de poner etiquetas en el PR? Entonces no está claro en qué categoría colocarlo y nuevamente tendrá que lidiar con esto manualmente, con cada PR por separado. Para solucionar este problema, podemos usar otra acción, el verificador de etiquetas, que verifica la presencia de etiquetas en la solicitud de extracción. Si no hay etiquetas requeridas, la verificación fallará y veremos un mensaje sobre esto en nuestra solicitud de extracción.
name: "Verify type labels"
on:
pull_request:
types: [opened, labeled, unlabeled, synchronize]
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: zwaldowski/match-label-action@v2
with:
allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'
Ahora cualquier solicitud de extracción debe marcarse con una de las etiquetas: tipo: corrección, tipo: características, tipo: documentación, tipo: pruebas, tipo: configuración.
Anotación automática de solicitudes de extracción
Ya que tocamos un tema como el trabajo efectivo con solicitudes de extracción, vale la pena hablar de una acción como el etiquetador, que coloca etiquetas en PR según los archivos que se han modificado. Por ejemplo, podemos marcar como [compilar] cualquier solicitud de extracción que contenga cambios en el directorio. .github/workflow.
Conectarlo es bastante sencillo:
name: "Auto-assign themes to PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
También necesitamos un archivo que describa la correspondencia entre los directorios del proyecto y los temas de la solicitud de extracción:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
No logré emparejar la acción que coloca etiquetas automáticamente en las solicitudes de extracción con la acción que verifica la presencia de etiquetas requeridas; match-label no quiere ver las etiquetas agregadas por el bot. Parece más fácil escribir una acción propia que combine ambas etapas. Pero incluso de esta forma es bastante cómodo de usar; es necesario seleccionar una etiqueta de la lista al crear una solicitud de extracción.
Es hora de implementar
Probé varias opciones de implementación a través de GitHub Actions (a través de ssh, a través de scp y usando docker-hub), y puedo decir que, lo más probable, encontrarás una manera de cargar el binario en el servidor, sin importar cuán torcida sea tu tubería. es.
Me gustó la opción de mantener toda la infraestructura en un solo lugar, así que veamos cómo implementarla en GitHub Packages (este es un repositorio de contenido binario, npm, jar, docker).
Script para crear una imagen de Docker y publicarla en paquetes de GitHub:
name: Deploy docker image
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# Build JAR:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean compile package -DskipTests
# Set global environment variables:
- name: set global env
id: global_env
run: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"
# Build Docker image:
- name: Build and tag image
run: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- name: Docker login
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publish image to github package repository:
- name: Publish image
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Primero, necesitamos crear el archivo JAR de nuestra aplicación, después de lo cual calculamos la ruta al registro de GitHub Docker y el nombre de nuestra imagen. Hay algunos trucos aquí que aún no hemos encontrado:
- una construcción como: echo “::set-output name=NOMBRE::VALOR” le permite establecer el valor de una variable en el paso actual, para que luego pueda leerse en todos los demás pasos.
- puede obtener el valor de la variable establecida en el paso anterior a través del identificador de este paso: ${{steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- La variable estándar GITHUB_REPOSITORY almacena el nombre del repositorio y su propietario (“propietario/nombre-repositorio”). Para eliminar todo de esta línea excepto el nombre del repositorio, usaremos la sintaxis bash: ${GITHUB_REPOSITORY#*/}
A continuación necesitamos crear la imagen de la ventana acoplable:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Inicie sesión en el registro:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Y publique la imagen en el repositorio de paquetes de GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Para indicar la versión de la imagen, utilizamos los primeros dígitos del hash SHA de la confirmación: GITHUB_SHA también hay matices aquí, si realiza tales compilaciones no solo al fusionarse con el maestro, sino también de acuerdo con la creación de la solicitud de extracción. evento, entonces SHA puede no coincidir con el hash que vemos en el historial de git, porque la acción de acciones/pago crea su propio hash único para evitar acciones de bloqueo en el PR.
Si todo salió bien, al abrir la sección de paquetes (https://github.com/antkorwin/github-actions/packages) en el repositorio, verá una nueva imagen de la ventana acoplable:
Allí también puede ver una lista de versiones de la imagen de la ventana acoplable.
Ya solo queda configurar nuestro servidor para que funcione con este registro y reiniciar el servicio. Probablemente hablaré sobre cómo hacer esto a través de systemd en otra ocasión.
Monitoreo
Veamos una opción simple sobre cómo realizar una verificación de estado de nuestra aplicación usando GitHub Actions. Nuestra aplicación de arranque tiene un actuador, por lo que ni siquiera necesitamos escribir una API para verificar su estado; ya hemos hecho todo por los perezosos. Sólo necesitas sacar el host: SERVER-URL:PORT/actuator/health
$ curl -v 127.0.0.1:8080/actuator/health
> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT
{"status":"UP"}
Todo lo que necesitamos es escribir una tarea para verificar el servidor usando cron, y si de repente no nos responde, le enviaremos una notificación por telegrama.
Primero, descubramos cómo ejecutar un flujo de trabajo cron:
on:
schedule:
- cron: '*/5 * * * *'
Es simple, ni siquiera puedo creer que en Github puedas crear eventos que no encajen en absoluto en webhooks. Los detalles están en la documentación:
Comprobemos el estado del servidor manualmente mediante curl:
jobs:
ping:
runs-on: ubuntu-18.04
steps:
- name: curl actuator
id: ping
run: |
echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"
- name: health check
run: |
if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
echo "health check is failed"
exit 1
fi
echo "It's OK"
Primero guardamos en una variable lo que el servidor respondió a la solicitud, en el siguiente paso comprobamos que el estado sea UP y, si no es así, salimos con error. Si necesita "abrumar" una acción con las manos, entonces salir de 1 - arma adecuada.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check of the:
${{secrets.SERVER_HOST}}/api/actuator/health
failed with the result:
${{ steps.ping.outputs.status }}
Enviamos a Telegram solo si la acción falló en el paso anterior. Para enviar un mensaje usamos appleboy/telegram-action; puedes leer sobre cómo obtener un token de bot y una identificación de chat en la documentación:
No olvides escribir los secretos en Github: URL del servidor y tokens para el bot de Telegram.
Bonus track: JIRA para los perezosos
Prometí que regresaríamos a JIRA y hemos regresado. Cientos de veces he observado una situación en stand-ups en la que los desarrolladores crearon una función, fusionaron una rama, pero olvidaron arrastrar el problema a JIRA. Por supuesto, si todo esto se hiciera en un solo lugar, sería más fácil, pero de hecho escribimos código en el IDE, fusionamos ramas en Bitbucket o GitHub y luego arrastramos las tareas a Jira, para esto necesitamos abrir nuevas ventanas. , a veces inicia sesión nuevamente, etc. Cuando recuerda perfectamente lo que debe hacer a continuación, no tiene sentido volver a abrir el tablero. Como resultado, por la mañana, en una reunión de pie, es necesario dedicar tiempo a actualizar el tablero de tareas.
GitHub también nos ayudará en esta tarea de rutina; para empezar, podemos arrastrar los problemas automáticamente a la columna code_review cuando enviamos una solicitud de extracción. Todo lo que necesitas hacer es seguir la convención de nomenclatura de sucursales:
[имя проекта]-[номер таска]-название
por ejemplo, si la clave del proyecto "GitHub Actions" es GA, entonces GA-8-jira-bot podría ser una rama para implementar la tarea GA-8.
La integración con JIRA funciona mediante acciones de Atlassian, no son perfectas, debo decir que algunas de ellas no me funcionaron del todo. Pero discutiremos sólo aquellos que definitivamente funcionan y se utilizan activamente.
Primero necesitas iniciar sesión en JIRA usando la acción: atlassian/gajira-login
jobs:
build:
runs-on: ubuntu-latest
name: Jira Workflow
steps:
- name: Login
uses: atlassian/gajira-login@master
env:
JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
Para hacer esto, necesita obtener un token en JIRA; aquí se describe cómo hacerlo:
Extraemos el identificador de la tarea del nombre de la sucursal:
- name: Find Issue
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo brach name: $GITHUB_HEAD_REF
echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Check Issue
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
Si buscas en el mercado de GitHub, puedes encontrar una acción para esta tarea, pero tuve que escribir lo mismo usando grep usando el nombre de la rama, porque esta acción de Atlassian no quería funcionar en mi proyecto de ninguna manera. , para descubrir qué estaba mal allí, más tiempo que hacer lo mismo con las manos.
Todo lo que queda es mover la tarea a la columna "Revisión de código" al crear una solicitud de extracción:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Hay una acción especial para esto en GitHub, todo lo que necesita es el ID del problema obtenido en el paso anterior y la autorización en JIRA que hicimos anteriormente.
De la misma manera, puede arrastrar tareas al fusionarlas con el maestro y otros eventos del flujo de trabajo de GitHub. En general, todo depende de tu imaginación y ganas de automatizar procesos rutinarios.
Hallazgos
Si observa el diagrama clásico de DEVOPS, hemos cubierto todas las etapas, excepto quizás operar, creo que si lo intenta, puede encontrar alguna acción en el mercado para la integración con el sistema de soporte técnico, por lo que asumiremos que el proceso giró. resulta ser exhaustivo y se pueden extraer conclusiones en función de su uso.
Pros:
- Marketplace con acciones listas para usar para todas las ocasiones, esto es genial. En la mayoría de ellos, también puede consultar el código fuente para comprender cómo resolver un problema similar o publicar una solicitud de función al autor directamente en el repositorio de GitHub.
- Seleccionar la plataforma de destino para el ensamblaje: Linux, mac os, windows es una característica bastante interesante.
- Github Packages es una gran cosa, es conveniente mantener toda la infraestructura en un solo lugar, no tienes que navegar por diferentes ventanas, todo está en un radio de uno o dos clics del mouse y está perfectamente integrado con GitHub Actions. La compatibilidad con el registro de Docker en la versión gratuita también es una buena ventaja.
- GitHub oculta secretos en los registros de compilación, por lo que usarlo para almacenar contraseñas y tokens no da tanto miedo. Durante todos mis experimentos, nunca pude ver el secreto en su forma pura en la consola.
- Gratis para proyectos de código abierto
Contras:
- YML, bueno, no me gusta. Cuando trabajo con un flujo de este tipo, el mensaje de confirmación más común que tengo es "arreglar el formato yml", a veces te olvidas de poner una pestaña en algún lugar, a veces la escribes en la línea incorrecta. En general, sentarse frente a una pantalla con un transportador y una regla no es la experiencia más placentera.
- DEBUG, depurar el flujo con confirmaciones, ejecutar una reconstrucción y enviar salida a la consola no siempre es conveniente, pero es más bien la categoría "estás exagerado"; estás acostumbrado a trabajar con IDEA conveniente, cuando puedes depurar cualquier cosa. .
- Puede escribir su acción en cualquier cosa si la envuelve en Docker, pero solo se admite javascript de forma nativa; por supuesto, esto es una cuestión de gustos, pero preferiría algo más en lugar de js.
Os recuerdo que el repositorio con todos los scripts está aquí:
La próxima semana estaré actuando con en la conferencia Heisenbug 2020 Piter. ¡No solo le diré cómo evitar errores al preparar datos de prueba, sino que también le compartiré mis secretos para trabajar con conjuntos de datos en aplicaciones Java!
Fuente: habr.com