Em maio de 2019, o GitHub anunciou o lançamento do serviço de Registro de Pacotes. Em seguida, já em agosto, foi anunciado o suporte ao CI / CD em Actions.
No artigo, vou lhe dizer que tipo de serviços e como isso pode ser usado no exemplo de um projeto pequeno para animais de estimação no GitHub.
Que tipo de serviços são esses?
O GitHub Actions é uma plataforma que permite gerenciar o ciclo de vida do software, cujo código fonte está hospedado no GitHub. De fato, o TravisCI, o CircleCI e muitas outras plataformas gratuitas de CI / CD receberam um novo concorrente na pessoa de Actions.
O GitHub Package Registry é o repositório central de artefatos; atualmente existem cinco tipos diferentes de artefatos suportados.
Tipos de artefato suportados em ações
Essa é uma oportunidade conveniente de ter todos os artefatos em um só lugar, porque nem sempre é aconselhável implantar o servidor Nexus ou Artifactory.
O GitHub está se tornando cada vez mais semelhante ao GitLab, e em algum lugar já superou um oponente, por exemplo, o GitLab ainda não suporta pacotes NuGet e gemas Ruby. De fato, se antes, para projetos de código aberto, você precisava conectar integrações externas ao GitHub, agora todos os ovos estão em uma cesta. Aqui, deixe todos decidirem se é bom ou ruim, mas pelo menos é conveniente.
Como tentar?
Atualmente, ambos os serviços estão no modo beta. Você pode se registrar para um teste beta nessas páginas .
A migração de outros serviços é muito simples; migrei vários dos meus projetos de estimação do TravisCI e DockerHub para o Actions and Package Registry, respectivamente.
Vou mostrar como fica em um exemplo. O projeto é o mais comum, escrevi sobre isso neste artigo. Nada complicado, o código LaTeX usual, com a ajuda dos quais artefatos são coletados (2 arquivos PDF), eles são publicados nas versões do GitHub. Para não baixar um monte de pacotes do LaTeX, escrevi um Dockerfile para que você possa trabalhar comodamente em qualquer sistema operacional.
Registro de pacote
Para começar a trabalhar com o Registro do Pacote em vez do DockerHub, você precisa executar apenas duas etapas simples.
Criamos um token nas configurações do GitHub (o token deve ter direitos para escrever e ler artefatos).
Página de criação de token
E então podemos autenticar com o token criado e enviar artefatos, é assim que é simples:
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
Observe que eu indiquei especificamente meu apelido no GitHub em letras minúsculas; caso contrário, você receberá um erro do 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
Aqui está o que parece na interface da web do GitHub:
Página de registro de pacote para imagens do Docker
Além das instruções para baixar a imagem mais recente, estão disponíveis estatísticas de download, a capacidade de baixar uma camada Docker separada por meio da interface da Web, o histórico de download da imagem também.
Acções
As ações são um pouco mais complicadas, mas para quem já trabalhou com qualquer outro sistema de CI / CD, não será difícil entender. A configuração em Ações é descrita pelo YAML declarativo, embora o HCL tenha sido usado anteriormente.
Alguns conceitos básicos (não intencionalmente vou traduzir as definições, acho que tudo está claro aqui):
- Fluxo de trabalho - um processo que gerencia o ciclo de vida do software (compilar, testar, empacotar, liberar, implantar) para o repositório
- Arquivo de fluxo de trabalho - o arquivo no qual o fluxo de trabalho é descrito, está localizado na raiz do repositório no diretório
.github/workflows/ - O trabalho é a cada execução do fluxo de trabalho; o trabalho é acionado; em determinado momento, muitos trabalhos podem ser iniciados
- Etapa - cada tarefa possui uma etapa; em cada etapa, você pode executar comandos ou ações
- Ação - um “plug-in” escrito por alguém, uma lista de muitas ações pode ser encontrada no repositório awesome-actions
- Ambiente virtual - o ambiente em que o Job é executado (na verdade, é uma máquina virtual no Windows, macOS ou Linux)
- Runner é um ambiente implementado para iniciar um trabalho, apenas um trabalho pode ser executado no Runner por vez
- Evento - um evento que aciona o Fluxo de Trabalho, por exemplo, Push, Pull Request, Webhook, Cron Job, etc.
- Artefato - artefatos (binários, imagens, logs, etc.)
É assim que a página da lista de tarefas no fluxo de trabalho se parece.
Limitações e proibições:
- 20 fluxos de trabalho por repositório
- 1000 solicitações de API por hora para todas as ações no repositório
- tempo máximo de trabalho - 6 horas
- 20 trabalhos podem trabalhar em paralelo no repositório (para todos os fluxos de trabalho)
- é proibido usar ações para mineração de criptomoeda e computação sem servidor
A documentação mais atual está disponível neste link .
E aqui estão os registros de um dos Jó
Exemplo
Vamos voltar ao exemplo, aqui está a minha configuração, vamos analisá-la em mais detalhes em partes.
Especifique um nome para o Fluxo de Trabalho e descreva em qual gatilho ele deve disparar (uma lista de todos os gatilhos é descrita na documentação ):
name: master-thesis on: [push]
Em qual ambiente virtual execute o trabalho:
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
A primeira etapa, em name: especifique o nome da Etapa (opcional) e em uses: qual Ação queremos usar, nesse caso, clonar o repositório:
steps: - name: Checkout repo uses: actions/checkout@v1
Na próxima etapa, não usamos Action, mas apenas um conjunto de comandos em que efetuamos login no Package Registry, coletamos a imagem do Docker e a enviamos ao repositório de imagens. No bloco env: definimos variáveis de ambiente, extraímos uma delas dos segredos:
- 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
Estou certo de que, em um futuro próximo, será exibida uma Ação que marcará e enviará automaticamente imagens em vez de escrever manualmente comandos do Docker.
Adicionando um segredo contendo um token do github
A próxima etapa após a criação dos PDFs é criar uma versão no GitHub e incluir os artefatos coletados nesta versão. Para criar automaticamente uma liberação, usamos uma Ação de terceiros , na qual no bloco if: você pode especificar a condição para iniciar a etapa - somente ao criar a tag:
- 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 }}
Sumário
Apesar do status beta, ambos os serviços funcionam bem, tenho certeza de que muitas coisas serão concluídas.
Em alguns pontos, pode ser inconveniente, não há variáveis globais, mas isso pode ser feito com muletas .
Gostei da abordagem do GitHub de abandonar o HCL em favor do YAML. Também gostei do suporte a muitos tipos de hosts, que são limites muito poupadores (por enquanto), vamos ver como isso acontece. Em geral, para pipelines simples em repositórios públicos no GitHub, esse grupo funcionará muito bem.
A tradução deste artigo já está no meio .