Fluxos de trabalho entre repositórios
Aprenda a encadear fluxos de trabalho entre diferentes repositórios para gerenciar dependências e orquestrar implantações complexas.
Fluxos de trabalho entre repositórios é uma aula grátis de CI/CD with GitHub Actions & DevOps Pipelines no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de CI/CD with GitHub Actions & DevOps Pipelines, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de CI/CD with GitHub Actions & DevOps Pipelines inclui 4 aulas no total.
Introdução aos fluxos de trabalho entre repositórios
No desenvolvimento moderno de software, os aplicativos geralmente consistem em vários componentes distribuídos por diferentes repositórios. Pense em microsserviços, bibliotecas compartilhadas ou configurações de implantação separadas.
Orquestrar fluxos de trabalho entre esses repositórios distintos permite maior modularidade e separação de responsabilidades. Nesta lição, você aprenderá como fazer isso com as Ações do GitHub.
Por que orquestrar entre repositórios?
Tradicionalmente, os fluxos de trabalho das Ações do GitHub têm escopo limitado a um único repositório. Mas e se você precisar:
- Compilar um artefato em um repositório e acionar uma implantação em outro?
- Usar um repositório de configuração compartilhada para acionar atualizações em vários repositórios de serviços?
- Aplicar políticas de segurança gerenciadas em um repositório central a todos os outros?
Os fluxos de trabalho entre repositórios fornecem a solução para esses cenários complexos.
Conectando repositórios: `repository_dispatch`
As Ações do GitHub oferecem um tipo especial de evento chamado repository_dispatch. Ele funciona como um webhook personalizado para seus repositórios do GitHub.
- Um fluxo de trabalho (o 'remetente') envia uma solicitação de API ao GitHub.
- Outro fluxo de trabalho (o 'receptor'), em um repositório diferente, escuta esse evento específico.
Isso permite acionar fluxos de trabalho programaticamente entre diferentes repositórios.
Configurando o fluxo de trabalho receptor
Para receber um evento repository_dispatch, é necessário configurar um fluxo de trabalho no repositório de destino para escutá-lo. Isso é feito usando a palavra-chave on:.
Veja como poderia ser um fluxo de trabalho em repo-B:
name: Receive Dispatch Event
on:
repository_dispatch:
types: [my-custom-event]
jobs:
process-event:
runs-on: ubuntu-latest
steps:
- name: Log event payload
run: |
echo "Event type: ${{ github.event.action }}"
echo "Payload: ${{ toJSON(github.event.client_payload) }}"Entendendo a configuração do receptor
No exemplo anterior:
on: repository_dispatch:informa ao GitHub que deve escutar esse evento.types: [my-custom-event]especifica que esse fluxo de trabalho só será executado se o evento enviado tiver o tipomy-custom-event. Você pode definir vários tipos.github.event.actionconterá o tipo do evento (por exemplo,my-custom-event).github.event.client_payloadcontém todos os dados personalizados enviados com o despacho.
Acionando o evento: envio de outro repositório
Para acionar um evento repository_dispatch, é necessário fazer uma solicitação HTTP POST à API do GitHub. Isso pode ser feito usando curl ou a CLI do GitHub (gh cli) dentro de outro fluxo de trabalho do GitHub Actions ou de um script.
Requisitos principais:
- O proprietário e o nome do repositório de destino.
- Um
typede evento que o fluxo de trabalho receptor esteja aguardando. - Um
client_payloadpara quaisquer dados personalizados. - Um token de acesso pessoal do GitHub (PAT) com escopo
repo.
Exemplo: acionando com `gh cli`
Este é um fluxo de trabalho em repo-A que envia um evento para repo-B. Observe como usamos um segredo para o token e passamos um client_payload.
name: Trigger Deploy Workflow
on:
push:
branches: [main]
jobs:
dispatch:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Install GitHub CLI
run: sudo apt-get update && sudo apt-get install gh -y
- name: Dispatch event to repo-B
env:
GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
run: |
gh api \
--method POST \
-H "Accept: application/vnd.github.v3+json" \
/repos/YOUR_ORG/repo-B/dispatches \
-f event_type='my-custom-event' \
-f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'Protegendo o acesso entre repositórios
O GITHUB_TOKEN padrão fornecido a um fluxo de trabalho é limitado ao repositório em que o fluxo está sendo executado. Para acionar eventos em *outro* repositório, é necessário um token com permissões mais amplas.
- Use um Token de Acesso Pessoal (PAT) com escopo
repo. - Armazene esse PAT como um segredo do repositório (por exemplo,
CROSS_REPO_PAT) no repositório acionador. - Nunca insira PATs diretamente nos arquivos de fluxo de trabalho.
Passando dados personalizados com `client_payload`
O client_payload é um objeto JSON que pode ser incluído ao acionar um evento. Ele é essencial para passar contexto ou dados do fluxo de trabalho acionador para o fluxo receptor.
Exemplos de dados que podem ser passados:
- O SHA do commit ou o nome da ramificação que acionou a compilação.
- Um ambiente de destino (por exemplo, "staging", "production").
- O número da versão de um artefato a ser implantado.
Lembre-se: o client_payload fica visível nos registros do fluxo de trabalho; portanto, evite informações confidenciais.
Verificação rápida sobre fluxos entre repositórios
Você aprendeu a orquestrar fluxos de trabalho entre diferentes repositórios do GitHub. Vamos testar sua compreensão dos componentes principais.
Recapitulação: orquestrando entre repositórios
Você aprendeu a implementar fluxos de trabalho entre repositórios usando repository_dispatch!
- Por quê: para gerenciar dependências e orquestrar implantações complexas em vários repositórios.
- Como: um fluxo de trabalho "emissor" faz uma chamada à API do GitHub, acionando um fluxo de trabalho "receptor" em outro repositório.
- Principal: o tipo de evento
repository_dispatche ostypescorrespondentes no fluxo de trabalho receptor. - Dados: use
client_payloadpara passar informações não confidenciais entre fluxos de trabalho. - Segurança: sempre use um PAT com escopo
repo, armazenado como segredo, para acessar outros repositórios.
Esse recurso avançado permite criar pipelines de CI/CD altamente flexíveis e desacoplados.
Perguntas Frequentes
A aula “Fluxos de trabalho entre repositórios” é grátis?
Sim — o texto completo de “Fluxos de trabalho entre repositórios” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de CI/CD with GitHub Actions & DevOps Pipelines, atualize para CoddyKit PRO. O curso de CI/CD with GitHub Actions & DevOps Pipelines inclui 4 aulas no total.
O que vou aprender em “Fluxos de trabalho entre repositórios”?
Aprenda a encadear fluxos de trabalho entre diferentes repositórios para gerenciar dependências e orquestrar implantações complexas. Você pratica CI/CD with GitHub Actions & DevOps Pipelines com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar CI/CD with GitHub Actions & DevOps Pipelines?
Nenhuma experiência prévia é necessária. CI/CD with GitHub Actions & DevOps Pipelines no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.
Quanto tempo leva a aula “Fluxos de trabalho entre repositórios”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de CI/CD with GitHub Actions & DevOps Pipelines?
Sim. Cada aula de CI/CD with GitHub Actions & DevOps Pipelines inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- CI/CD para monorrepositórios
- Fluxos de trabalho entre repositórios
- Gerenciamento centralizado de fluxos de trabalho
- Filtragem por caminho e compilações seletivas