Muitas vezes tenho que construir um pipeline para construir projetos em Java. Às vezes é de código aberto, às vezes não. Recentemente, decidi tentar mover alguns dos meus repositórios do Travis-CI e TeamCity para o GitHub Actions, e foi isso que resultou.
O que iremos automatizar?
Primeiramente precisamos de um projeto que iremos automatizar, vamos fazer uma pequena aplicação em Spring boot/Java 11/Maven. Para os propósitos deste artigo, não estaremos interessados na lógica do aplicativo; a infraestrutura em torno do aplicativo é importante para nós, portanto, um simples controlador de API REST será suficiente para nós.
Você pode ver as fontes aqui: Todas as etapas da construção de um pipeline são refletidas nas solicitações pull deste projeto.
JIRA e planejamento
Vale dizer que normalmente usamos o JIRA como issue tracker, então vamos criar um quadro separado para este projeto e adicionar os primeiros problemas lá:
Um pouco mais tarde voltaremos às coisas interessantes que o JIRA e o GitHub podem oferecer em combinação.
Automatizamos a montagem do projeto
Nosso projeto de teste é construído via maven, então construí-lo é bastante simples, tudo o que precisamos é do pacote mvn clean.
Para fazer isso usando Github Actions, precisaremos criar um arquivo no repositório descrevendo nosso fluxo de trabalho, isso pode ser feito com um arquivo yml normal, não posso dizer que gosto de “programação yml”, mas o que podemos fazer - fazemos isso no diretório .github/ workflow/ arquivo build.yml no qual descreveremos as ações ao construir o branch 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 é uma descrição do evento em que nosso roteiro será lançado.
em: pull_request/push — indica que este fluxo de trabalho precisa ser iniciado sempre que um push é feito para o mestre e solicitações pull são criadas.
A seguir está uma descrição das tarefas (empregos) e etapas de execução (passos) para cada tarefa.
corre em - aqui podemos selecionar o SO alvo, surpreendentemente, você pode até escolher Mac OS, mas em repositórios privados isso é bastante caro (comparado ao Linux).
usos permite reutilizar outras ações, por exemplo, usando a ação actions/setup-java instalamos o ambiente para Java 11.
Por meio de de podemos especificar os parâmetros com os quais lançamos a ação, essencialmente estes são os argumentos que serão passados para a ação.
Tudo o que resta é executar a construção do projeto com Maven: run: mvn -B clean package bandeira -B diz que precisamos de um modo não interativo para que o especialista de repente não queira nos perguntar algo
Ótimo! Agora, toda vez que você se compromete com o master, a construção do projeto é iniciada.
Automatizando lançamentos de testes
A montagem é boa, mas na realidade um projeto pode ser montado com segurança, mas não funcionar. Portanto, o próximo passo é automatizar as execuções de teste. Além disso, é bastante conveniente observar os resultados da aprovação nos testes ao fazer uma revisão de PR - você tem certeza de que os testes foram aprovados e ninguém se esqueceu de executar seu branch antes de fazer a mesclagem.
Executaremos testes ao criar uma solicitação pull e mesclar no master e, ao mesmo tempo, adicionaremos a criação de um relatório de cobertura de 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 cobrir os testes, eu uso o codecov em conjunto com o plugin jacoco. codecov tem sua própria ação, mas precisa de um token para funcionar com nossa solicitação pull:
${{ secrets.CODECOV_TOKEN }} — veremos essa construção mais de uma vez, secrets é um mecanismo para armazenar segredos no GitHub, podemos escrever lá senhas/tokens/hosts/urls e outros dados que não devem ser incluídos na base de código do repositório.
Você pode adicionar uma variável aos segredos nas configurações do repositório no GitHub:
Você pode obter um token em Após autorização via GitHub, para adicionar um projeto público basta seguir um link como este: /[nome do repositório]. Um repositório privado também pode ser adicionado; para fazer isso, você precisa conceder direitos codecov ao aplicativo no Github.
Adicione o plugin jacoco ao arquivo 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 entrará em cada uma de nossas solicitações pull e adicionará um gráfico de mudança de cobertura:
Vamos adicionar um analisador estático
Na maioria dos meus projetos de código aberto eu uso nuvem sonar para análise estática de código, é muito fácil conectar-se ao travis-ci. Portanto, é uma etapa lógica ao migrar para o GitHub Actions fazer o mesmo. O mercado de ações é uma coisa legal, mas dessa vez me decepcionou um pouco, pois por hábito encontrei a ação que precisava e adicionei ao fluxo de trabalho. Mas descobriu-se que o sonar não oferece suporte ao trabalho por meio de uma ação para análise de projetos no maven ou no gradle. Claro que isso está escrito na documentação, mas quem lê?!
Não é possível através de uma ação, então faremos através do plugin 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 - pode ser obtido em e você precisa registrá-lo em segredo. GITHUB_TOKEN - este é um token integrado gerado pelo GitHub, com a ajuda do qual sonarcloud[bot] poderá fazer login no Git para nos deixar mensagens em pull requests.
Dsonar.projectKey — o nome do projeto no sonar, você pode vê-lo nas configurações do projeto.
Dsonar.organização — nome da organização do GitHub.
Fazemos uma solicitação pull e esperamos que o sonarcloud[bot] chegue nos comentários:
Gerenciamento de Liberação
A compilação foi configurada, os testes foram executados e podemos fazer um lançamento. Vejamos como o GitHub Actions pode tornar o gerenciamento de versões muito mais fácil.
No trabalho, tenho projetos cuja base de código está no bitbucket (tudo é como naquela história “escrevo no bitbucket durante o dia, comprometo no GitHub à noite”). Infelizmente, o bitbucket não possui ferramentas integradas de gerenciamento de versão. Isso é um problema, pois para cada release você tem que criar manualmente uma página no confluence e jogar lá todos os recursos incluídos no release, pesquisar nos palácios da mente, tarefas no jira, commits no repositório. Há muitas chances de cometer um erro, você pode esquecer algo ou inserir algo que já foi lançado da última vez, às vezes simplesmente não está claro como classificar uma solicitação pull - é um recurso ou uma correção de bug, ou testes de edição, ou algo infraestrutural.
Como as ações do GitHub podem nos ajudar? Existe um ótimo rascunho de ação - release, que permite definir um modelo de arquivo de notas de versão para configurar categorias de solicitações pull e agrupá-las automaticamente no arquivo de notas de versão:
Modelo de exemplo para configurar um relatório (.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
Adicione um script para gerar um rascunho de versão (.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 solicitações pull de agora em diante serão coletadas automaticamente nas notas de lançamento - mágica!
Aqui pode surgir a pergunta: e se os desenvolvedores esquecerem de colocar tags no PR? Então não fica claro em qual categoria colocá-lo e novamente você terá que lidar com isso manualmente, com cada PR separadamente. Para corrigir esse problema, podemos usar outra ação - verificador de rótulo - que verifica a presença de tags na solicitação pull. Se não houver tags obrigatórias, a verificação falhará e veremos uma mensagem sobre isso em nossa solicitação pull.
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 qualquer solicitação pull deve ser marcada com uma das tags: type:fix, type:features, type:documentation, type:tests, type:config.
Anotação automática de pull requests
Já que abordamos um tópico como trabalho eficaz com solicitações pull, vale a pena falar sobre uma ação como rotulador, que coloca tags no PR com base em quais arquivos foram alterados. Por exemplo, podemos marcar como [build] qualquer solicitação pull que contenha alterações no diretório .github/workflow.
Conectar é bastante simples:
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 }}
Também precisamos de um arquivo descrevendo a correspondência entre os diretórios do projeto e os tópicos do pull request:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Não consegui emparelhar a ação que coloca rótulos automaticamente em pull requests com a ação que verifica a presença de rótulos obrigatórios; match-label não quer ver os rótulos adicionados pelo bot. Parece mais fácil escrever sua própria ação que combine os dois estágios. Mas mesmo neste formato é bastante conveniente de usar: você precisa selecionar um rótulo da lista ao criar uma solicitação pull.
É hora de implantar
Tentei várias opções de implantação via GitHub Actions (via ssh, via scp e usando docker-hub) e posso dizer que, muito provavelmente, você encontrará uma maneira de fazer upload do binário para o servidor, não importa quão torto seja seu pipeline é.
Gostei da opção de manter toda a infraestrutura em um só lugar, então vamos ver como implantar pacotes no GitHub (este é um repositório para conteúdo binário, npm, jar, docker).
Script para construir uma imagem docker e publicá-la em pacotes 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 }}"
Primeiro, precisamos construir o arquivo JAR do nosso aplicativo, após o qual calculamos o caminho para o registro do Docker do GitHub e o nome da nossa imagem. Existem alguns truques aqui que ainda não descobrimos:
- uma construção como: echo “::set-output name=NAME::VALUE” permite definir o valor de uma variável na etapa atual, para que ela possa ser lida em todas as outras etapas.
- você pode obter o valor da variável definida na etapa anterior através do identificador desta etapa: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- A variável padrão GITHUB_REPOSITORY armazena o nome do repositório e seu proprietário (“proprietário/nome do repositório”). Para cortar tudo desta linha, exceto o nome do repositório, usaremos a sintaxe bash: ${GITHUB_REPOSITORY#*/}
Em seguida, precisamos construir a imagem docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Faça login no registro:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
E publique a imagem no repositório de pacotes GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Para indicar a versão da imagem, usamos os primeiros dígitos do hash SHA do commit - GITHUB_SHA também há nuances aqui, se você fizer tais compilações não apenas ao mesclar no master, mas também de acordo com a criação do pull request evento, então o SHA pode não corresponder ao hash que vemos no histórico do git, porque a ação actions/checkout cria seu próprio hash exclusivo para evitar ações de impasse no PR.
Se tudo deu certo, abrindo a seção de pacotes (https://github.com/antkorwin/github-actions/packages) no repositório, você verá uma nova imagem do docker:
Lá você também pode ver uma lista de versões da imagem do docker.
Resta configurar nosso servidor para funcionar com este registro e reiniciar o serviço. Provavelmente falarei sobre como fazer isso através do systemd em outra ocasião.
Monitoramento
Vejamos uma opção simples sobre como fazer uma verificação de integridade de nosso aplicativo usando GitHub Actions. Nosso aplicativo de inicialização possui um atuador, então nem precisamos escrever uma API para verificar seu status; já fizemos tudo para os preguiçosos. Você só precisa puxar o 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"}
Basta escrever uma tarefa para verificar o servidor usando o cron, e se de repente ele não nos responder, enviaremos uma notificação via telegrama.
Primeiro, vamos descobrir como executar um fluxo de trabalho cron:
on:
schedule:
- cron: '*/5 * * * *'
É simples, nem acredito que no Github você possa criar eventos que não cabem em webhooks. Os detalhes estão na documentação:
Vamos verificar o status do servidor manualmente via 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"
Primeiro salvamos em uma variável o que o servidor respondeu à solicitação, na próxima etapa verificamos se o status é UP e, se não for o caso, saímos com erro. Se você precisar “sobrecarregar” uma ação com as mãos, então sair 1 - arma adequada.
- 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 para telegrama somente se a ação falhou na etapa anterior. Para enviar uma mensagem usamos appleboy/telegram-action; você pode ler sobre como obter um token de bot e um ID de chat na documentação:
Não se esqueça de escrever nos segredos do Github: URL do servidor e tokens do bot do telegrama.
Faixa bônus - JIRA para os preguiçosos
Prometi que voltaríamos ao JIRA e voltamos. Centenas de vezes observei uma situação em stand-ups quando os desenvolvedores criavam um recurso, fundiam um branch, mas esqueciam de arrastar o problema para o JIRA. Claro, se tudo isso fosse feito em um só lugar, seria mais fácil, mas na verdade escrevemos o código no IDE, mesclamos as ramificações no bitbucket ou GitHub e depois arrastamos as tarefas para o Jira, para isso precisamos abrir novas janelas , às vezes faça login novamente e etc. Quando você se lembra perfeitamente do que precisa fazer a seguir, não faz sentido abrir o quadro novamente. Como resultado, pela manhã, em uma reunião stand-up, você precisa gastar tempo atualizando o quadro de tarefas.
O GitHub também nos ajudará nessa tarefa rotineira; para começar, podemos arrastar problemas automaticamente para a coluna code_review quando enviamos uma solicitação pull. Tudo que você precisa fazer é seguir a convenção de nomenclatura de branch:
[имя проекта]-[номер таска]-название
por exemplo, se a chave do projeto "GitHub Actions" for GA, então GA-8-jira-bot poderia ser um ramo para implementar a tarefa GA-8.
A integração com o JIRA funciona através de ações do Atlassian, elas não são perfeitas, devo dizer que algumas delas não funcionaram nada para mim. Mas discutiremos apenas aqueles que definitivamente funcionam e são usados ativamente.
Primeiro você precisa fazer login no JIRA usando a ação: 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 fazer isso, você precisa obter um token no JIRA, como fazer isso está descrito aqui:
Extraímos o identificador da tarefa do nome da ramificação:
- 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 você pesquisar no marketplace do GitHub, poderá encontrar uma ação para esta tarefa, mas tive que escrever a mesma coisa usando grep usando o nome do branch, pois esta ação da Atlassian não queria funcionar no meu projeto de forma alguma , para descobrir o que havia de errado ali - mais tempo do que fazer a mesma coisa com as mãos.
Resta mover a tarefa para a coluna “Revisão de código” ao criar uma solicitação pull:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Existe uma ação especial para isso no GitHub, bastando o ID do problema obtido na etapa anterior e a autorização no JIRA que fizemos acima.
Da mesma forma, você pode arrastar tarefas ao mesclar no mestre e outros eventos do fluxo de trabalho do GitHub. Em geral, tudo depende da sua imaginação e desejo de automatizar processos rotineiros.
Descobertas
Se você olhar o diagrama DEVOPS clássico, cobrimos todas as etapas, exceto talvez operar, acho que se você tentar, poderá encontrar alguma ação no mercado para integração com o sistema de help-desk, então vamos assumir que o pipeline virou ser completo e conclusões podem ser tiradas com base em seu uso.
Prós:
- Marketplace com ações prontas para todas as ocasiões, isso é muito legal. Na maioria deles, você também pode consultar o código-fonte para entender como resolver um problema semelhante ou postar uma solicitação de recurso ao autor diretamente no repositório GitHub.
- Selecionar a plataforma alvo para montagem: Linux, Mac OS, Windows é um recurso bastante interessante.
- Github Packages é ótimo, é conveniente manter toda a infraestrutura em um só lugar, você não precisa navegar por janelas diferentes, tudo está no raio de um ou dois cliques do mouse e está perfeitamente integrado com GitHub Actions. O suporte ao registro Docker na versão gratuita também é uma boa vantagem.
- O GitHub esconde segredos nos logs de construção, portanto, usá-lo para armazenar senhas e tokens não é tão assustador. Durante todos os meus experimentos, nunca consegui ver o segredo em sua forma pura no console.
- Gratuito para projetos de código aberto
Contras:
- YML, bem, eu não gosto dele. Ao trabalhar com esse fluxo, a mensagem de commit mais comum que tenho é “corrigir formato yml”, então você esquece de colocar uma guia em algum lugar ou escreve na linha errada. Em geral, sentar em frente a uma tela com transferidor e régua não é a experiência mais agradável.
- DEBUG, depurar o fluxo com commits, executar uma reconstrução e enviar para o console nem sempre é conveniente, mas é mais da categoria “você está exagerado”; você está acostumado a trabalhar com IDEA conveniente, quando você pode depurar qualquer coisa .
- Você pode escrever sua ação em qualquer coisa se envolvê-la no Docker, mas apenas javascript é suportado nativamente, é claro que isso é uma questão de gosto, mas eu preferiria outra coisa em vez de js.
Deixe-me lembrar que o repositório com todos os scripts está aqui:
Na próxima semana estarei me apresentando com na conferência Heisenbug 2020 Piter. Não apenas lhe direi como evitar erros ao preparar dados de teste, mas também compartilharei meus segredos para trabalhar com conjuntos de dados em aplicativos Java!
Fonte: habr.com