Circles of hell con GitHub Actions (construción dunha canalización de CI/CD para un proxecto Java)

Moitas veces teño que construír un pipeline para construír proxectos en Java. Ás veces é de código aberto, outras non. Recentemente decidín tentar mover algúns dos meus repositorios de Travis-CI e TeamCity a GitHub Actions, e isto é o que saíu.

Que imos automatizar?

En primeiro lugar, necesitamos un proxecto que imos automatizar, imos facer unha pequena aplicación en Spring boot/Java 11/Maven. Para os efectos deste artigo, non nos interesará nada a lóxica da aplicación; a infraestrutura que rodea a aplicación é importante para nós, polo que un simple controlador da API REST será suficiente para nós.

Podes ver as fontes aquí: github.com/antkorwin/github-actions Todas as fases da construción dun gasoduto reflíctese nas solicitudes de extracción deste proxecto.

JIRA e planificación

Paga a pena dicir que normalmente usamos JIRA como rastreador de problemas, así que imos crear un taboleiro separado para este proxecto e engadir os primeiros problemas alí:

Un pouco máis tarde volveremos ás cousas interesantes que JIRA e GitHub poden ofrecer en combinación.

Automatizamos a montaxe do proxecto

O noso proxecto de proba está construído a través de Maven, polo que crealo é bastante sinxelo, todo o que necesitamos é o paquete mvn clean.

Para facelo usando Github Actions, necesitaremos crear un ficheiro no repositorio que describa o noso fluxo de traballo, isto pódese facer cun ficheiro yml normal, non podo dicir que me guste a "programación yml", pero que podemos facer - facémolo no directorio workflow .github// ficheiro build.yml no que describiremos as accións á hora de construír a rama mestra:

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 é unha descrición do evento no que se lanzará o noso guión.

en: pull_request/push — indica que este fluxo de traballo debe iniciarse cada vez que se fai un push ao mestre e se crean solicitudes de extracción.

A continuación móstrase unha descrición das tarefas (emprego) e pasos de execución (pasos) para cada tarefa.

corre en marcha - Aquí podemos seleccionar o sistema operativo de destino, sorprendentemente, incluso pode escoller Mac OS, pero nos repositorios privados isto é bastante caro (en comparación con Linux).

usa permítelle reutilizar outras accións, por exemplo, usando a acción action/setup-java que instalamos o ambiente para Java 11.

Por medio de con podemos especificar os parámetros cos que iniciamos a acción, esencialmente estes son os argumentos que se pasarán á acción.

Todo o que queda é executar a construción do proxecto en Maven: run: mvn -B clean package bandeira -B di que necesitamos un modo non interactivo para que o experto de súpeto non queira preguntarnos algo

Genial! Agora, cada vez que te comprometes co mestre, comeza a construción do proxecto.

Automatización de lanzamentos de proba

A montaxe é boa, pero en realidade, un proxecto pódese montar con seguridade, pero non funciona. Polo tanto, o seguinte paso é automatizar as probas. Ademais, é bastante conveniente mirar os resultados da superación das probas cando fas unha revisión de PR: sabes con certeza que as probas pasan e ninguén se esqueceu de executar a súa rama antes de facer unha fusión.

Realizaremos probas ao crear unha solicitude de extracción e fusionaremos no mestre, e ao mesmo tempo engadiremos a creación dun informe sobre a cobertura do 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 as probas, uso codecov xunto co complemento jacoco. codecov ten a súa propia acción, pero necesita un token para traballar coa nosa solicitude de extracción:

${{ secrets.CODECOV_TOKEN }} — veremos esta construción máis dunha vez, secrets é un mecanismo para almacenar segredos en GitHub, alí podemos escribir contrasinais/tokens/hosts/urls e outros datos que non deberían incluírse no código base do repositorio.

Podes engadir unha variable aos segredos na configuración do repositorio de GitHub:

Podes conseguir un token en codecov.io Despois da autorización a través de GitHub, para engadir un proxecto público só tes que seguir unha ligazón como esta: Nome de usuario de GitHub/[nome do repositorio]. Tamén se pode engadir un repositorio privado; para facelo, cómpre dar dereitos de codecov á aplicación en Github.

Engade o complemento jacoco ao ficheiro 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>

Agora o bot codecov introducirá cada unha das nosas solicitudes de extracción e engadirá un gráfico de cambio de cobertura:

Imos engadir un analizador estático

Na maioría dos meus proxectos de código aberto uso sonar cloud para a análise de código estático, é bastante sinxelo conectarse a travis-ci. Polo tanto, é un paso lóxico ao migrar a GitHub Actions para facer o mesmo. O mercado de accións é algo interesante, pero esta vez decepcionoume un pouco, porque por costume atopei a acción que necesitaba e engadína ao fluxo de traballo. Pero resultou que o sonar non admite traballar a través dunha acción para analizar proxectos en maven ou gradle. Por suposto, isto está escrito na documentación, pero quen o le?

Non é posible mediante unha acción, así que farémolo a través do 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 - pódese obter en sonarcloud.io e cómpre rexistralo en segredo. GITHUB_TOKEN - este é un token integrado que xera GitHub, coa axuda do cal sonarcloud[bot] poderá iniciar sesión en Git para deixarnos mensaxes en solicitudes de extracción.

Dsonar.projectKey — o nome do proxecto no sonar, podes velo na configuración do proxecto.

Dsonar.organización — nome da organización de GitHub.

Facemos unha solicitude de extracción e agardamos a que veña sonarcloud[bot] nos comentarios:

Xestión de lanzamentos

Configurouse a compilación, executáronse as probas e podemos facer un lanzamento. Vexamos como as accións de GitHub poden facilitar moito a xestión de lanzamentos.

No traballo, teño proxectos cuxa base de código está en bitbucket (todo é como nesa historia "Escribo a bitbucket durante o día, comprométome a GitHub pola noite"). Desafortunadamente, bitbucket non ten ferramentas de xestión de versións integradas. Isto é un problema, porque para cada lanzamento hai que crear manualmente unha páxina en confluencia e botar alí todas as funcións incluídas na versión, buscar polos palacios da mente, tarefas en jira, commits no repositorio. Hai moitas posibilidades de cometer un erro, podes esquecer algo ou introducir algo que xa se publicou a última vez, ás veces simplemente non está claro como clasificar unha solicitude de extracción: é unha función ou unha corrección de erros, ou probas de edición ou algo de infraestruturas.

Como poden axudarnos as accións de GitHub? Hai unha gran acción: o redactor de versións, permítelle configurar un modelo de ficheiro de notas de versión para configurar categorías de solicitudes de extracción e agrupalas automaticamente no ficheiro de notas de publicación:

Modelo de exemplo 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

Engade un script para xerar 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 as solicitudes de extracción a partir de agora recolleranse en notas de versión automaticamente, ¡máxica!

Aquí pode xurdir a pregunta: e se os desenvolvedores esquecen poñer etiquetas no PR? Entón non está claro en que categoría colocalo e, de novo, terás que tratalo manualmente, con cada PR por separado. Para solucionar este problema, podemos utilizar outra acción - o verificador de etiquetas - que comproba a presenza de etiquetas na solicitude de extracción. Se non hai etiquetas obrigatorias, a comprobación fallará e veremos unha mensaxe ao respecto na nosa solicitude 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'

Agora calquera pull-request debe marcarse cunha das etiquetas: type:fix, type:features, type:documentation, type:tests, type:config.

Anotación automática de solicitudes de extracción

Xa que tocamos un tema como o traballo efectivo con solicitudes de extracción, paga a pena falar dunha acción como o etiquetador, que pon etiquetas en PR en función dos ficheiros que se cambiaron. Por exemplo, podemos marcar como [build] calquera solicitude de extracción que conteña cambios no directorio .github/workflow.

Conectalo é bastante sinxelo:

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 }}

Tamén necesitamos un ficheiro que describa a correspondencia entre os directorios do proxecto e os temas da solicitude 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/**"

Non conseguín emparellar a acción que coloca automaticamente etiquetas nas solicitudes de extracción coa acción que verifica a presenza das etiquetas necesarias; match-label non quere ver as etiquetas engadidas polo bot. Parece máis doado escribir a túa propia acción que combine ambas as etapas. Pero mesmo neste formulario é moi cómodo de usar; cómpre seleccionar unha etiqueta da lista ao crear unha solicitude de extracción.

É hora de despregar

Probei varias opcións de implementación a través de accións de GitHub (a través de ssh, a través de scp e usando docker-hub), e podo dicir que, moi probablemente, atoparás un xeito de cargar o binario ao servidor, por moi mal que sexa a túa canalización. é.

Gustoume a opción de manter toda a infraestrutura nun só lugar, así que vexamos como implementar nos paquetes GitHub (este é un repositorio de contido binario, npm, jar, docker).

Script para construír unha imaxe docker e publicala en paquetes 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 }}"

En primeiro lugar, necesitamos construír o ficheiro JAR da nosa aplicación, despois de que calculamos o camiño ao rexistro docker de GitHub e o nome da nosa imaxe. Aquí hai algúns trucos que aínda non atopamos:

• unha construción como: echo “::set-output name=NAME::VALUE” permítelle establecer o valor dunha variable no paso actual, para que se poida ler en todos os demais pasos.
• pode obter o valor da variable definida no paso anterior a través do identificador deste paso: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• A variable estándar GITHUB_REPOSITORY almacena o nome do repositorio e o seu propietario ("owner/repo-name"). Para cortar todo desta liña excepto o nome do repositorio, utilizaremos a sintaxe bash: ${GITHUB_REPOSITORY#*/}

A continuación, necesitamos construír a imaxe docker:

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

Inicie sesión no rexistro:

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

E publica a imaxe no repositorio de paquetes de GitHub:

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

Para indicar a versión da imaxe, usamos os primeiros díxitos do hash SHA do commit - GITHUB_SHA tamén hai matices aquí, se fai tales compilacións non só ao combinar no mestre, senón tamén segundo a creación da solicitude de extracción. evento, entón SHA pode non coincidir co hash que vemos no historial de git, porque a acción de accións/checkout fai o seu propio hash único para evitar accións de bloqueo no PR.

Se todo funcionou ben, abrindo a sección de paquetes (https://github.com/antkorwin/github-actions/packages) no repositorio, verá unha nova imaxe docker:

Alí tamén podes ver unha lista de versións da imaxe docker.

Só queda configurar o noso servidor para que funcione con este rexistro e reiniciar o servizo. Probablemente falarei de como facelo a través de systemd noutra vez.

Seguimento

Vexamos unha opción sinxela sobre como facer unha comprobación de saúde da nosa aplicación usando GitHub Actions. A nosa aplicación de arranque ten un actuador, polo que nin sequera necesitamos escribir unha API para comprobar o seu estado; xa fixemos todo para os preguiceiros. Só tes que tirar do 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 o que necesitamos é escribir unha tarefa para comprobar o servidor mediante cron, e se de súpeto non nos responde, enviarémoslle unha notificación por telegrama.

Primeiro, imos descubrir como executar un fluxo de traballo cron:

on:
  schedule:
    - cron:  '*/5 * * * *'

É sinxelo, nin sequera podo crer que en Github poidas crear eventos que non encaixan en absoluto nos webhooks. Os detalles están na documentación: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Comprobamos o estado do 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"

En primeiro lugar, gardamos nunha variable o que o servidor respondeu á solicitude, no seguinte paso comprobamos que o estado está ARRIBA e, se non é o caso, saímos cun erro. Se precisas "abordar" unha acción coas túas mans, entón saída 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 só se a acción fallou no paso anterior. Para enviar unha mensaxe usamos appleboy/telegram-action; podes ler sobre como obter un token de bot e identificador de chat na documentación: github.com/appleboy/telegram-action

Non esquezas escribir nos segredos en Github: URL para o servidor e tokens para o bot de telegram.

Bonus track - JIRA para os preguiceiros

Prometín que volveriamos a JIRA e volvemos. Centos de veces observei unha situación nos stand-ups cando os desenvolvedores fixeron unha función, fusionaron unha rama, pero esquecín arrastrar o problema a JIRA. Por suposto, se todo isto se fixera nun só lugar, sería máis doado, pero de feito escribimos código no IDE, fusionamos ramas en bitbucket ou GitHub e despois arrastramos as tarefas a Jira, para iso necesitamos abrir novas fiestras. , ás veces inicia sesión de novo e etc. Cando lembras perfectamente o que tes que facer a continuación, non ten sentido volver abrir o taboleiro. Como resultado, pola mañá nun standup cómpre dedicar tempo a actualizar o taboleiro de tarefas.

GitHub tamén nos axudará con esta tarefa rutineira; para comezar, podemos arrastrar os problemas automaticamente á columna code_review cando enviemos unha solicitude de extracción. Todo o que tes que facer é seguir a convención de nomeamento das ramas:

[имя проекта]-[номер таска]-название

por exemplo, se a clave do proxecto "Accións de GitHub" é GA, entón GA-8-jira-bot podería ser unha rama para implementar a tarefa GA-8.

A integración con JIRA funciona mediante accións de Atlassian, non son perfectas, debo dicir que algunhas delas non me funcionaron para nada. Pero discutiremos só aqueles que definitivamente funcionan e se usan activamente.

Primeiro cómpre iniciar sesión en JIRA usando a 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 iso, necesitas obter un token en JIRA, como facelo descríbese aquí: confluence.atlassian.com/cloud/api-tokens-938839638.html

Extraemos o identificador da tarefa do nome da rama:

  - 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}}

Se buscas no mercado de GitHub, podes atopar unha acción para esta tarefa, pero tiven que escribir o mesmo usando grep usando o nome da rama, porque esta acción de Atlassian non quería traballar no meu proxecto de ningún xeito. , para descubrir o que estaba mal alí - máis que facer o mesmo coas mans.

Todo o que queda é mover a tarefa á columna "Revisión de código" ao crear unha solicitude de extracción:

  - name: Transition issue
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

Hai unha acción especial para isto en GitHub, o único que necesita é o ID do problema obtido no paso anterior e a autorización en JIRA que fixemos anteriormente.

Do mesmo xeito, podes arrastrar tarefas ao combinar co mestre e outros eventos do fluxo de traballo de GitHub. En xeral, todo depende da túa imaxinación e do teu desexo de automatizar os procesos rutineiros.

Descubrimentos

Se observas o diagrama clásico DEVOPS, cubrimos todas as etapas, excepto quizais operar, creo que se o intentas, podes atopar algunha acción no mercado para a integración co sistema de mesa de axuda, polo que asumiremos que a canalización virou debe ser exhaustivo e pódense extraer conclusións en función do seu uso.

Pros:

• Mercado con accións preparadas para todas as ocasións, é moi xenial. Na maioría deles, tamén podes mirar o código fonte para comprender como resolver un problema similar ou enviar unha solicitude de función ao autor directamente no repositorio de GitHub.
• Seleccionar a plataforma de destino para a montaxe: Linux, mac os, windows é unha característica bastante interesante.
• Github Packages é unha gran cousa, é conveniente manter toda a infraestrutura nun só lugar, non tes que navegar por diferentes ventás, todo está nun radio de un ou dous clics do rato e está perfectamente integrado con GitHub Actions. O soporte do rexistro de Docker na versión gratuíta tamén é unha boa vantaxe.
• GitHub oculta segredos nos rexistros de compilación, polo que usalo para almacenar contrasinais e tokens non é tan asustado. Durante todos os meus experimentos, nunca puiden ver o segredo na súa forma pura na consola.
• Gratuíto para proxectos de código aberto

Contras:

• YML, ben, non me gusta. Cando traballo con tal fluxo, a mensaxe de confirmación máis común que teño é "fixar o formato yml", entón esquezas poñer unha pestana nalgún lugar ou escribes na liña incorrecta. En xeral, sentarse diante dunha pantalla cun transportador e unha regra non é a experiencia máis agradable.
• DEPURAR, depurar o fluxo con commits, executar unha reconstrución e sair á consola non sempre é conveniente, pero é máis da categoría "estás esaxerado"; estás afeito a traballar con IDEA conveniente, cando podes depurar calquera cousa. .
• Podes escribir a túa acción en calquera cousa se a envolves en Docker, pero só se admite javascript de forma nativa, por suposto que é cuestión de gustos, pero preferiría outra cousa en lugar de js.

Lémbrolle que o repositorio con todos os scripts está aquí: github.com/antkorwin/github-actions

A vindeira semana estarei coa actuación informe na conferencia Heisenbug 2020 Piter. Vouche dicir non só como evitar erros ao preparar os datos de proba, senón que tamén compartirei os meus segredos de traballar con conxuntos de datos en aplicacións Java.

Fonte: www.habr.com