GitHub Actions configurações

  • Versão de lançamento: Yokohama
  • Atualizado 30 de jan. de 2025
  • 4 min. de leitura
  • Informações de configuração em GitHub Actions, como segredos, fluxos de trabalho e limitações.

    Segredos em GitHub Actions

    Crie segredos (credenciais) no repositório GitHub ou na organização GitHub. Segredos são variáveis de ambiente (criptografadas) que você cria em uma organização ou repositório. Esses segredos estão disponíveis para uso em GitHub Actions fluxos de trabalho. Para obter mais informações, consulte Segredos criptografados.

    Segredo Descrição
    SN_INSTÂNCIA_URL ServiceNow URL da instância. Por exemplo, https://<instance_name> .service-now.com.
    SN_ORCHESTRAÇÃO_TOOL_ID Sys_id da ferramenta GitHub criada na instância ServiceNow.
    SN_DEVOPS_INTEGRATION_TOKEN Token secreto da ferramenta GitHub criada em DevOps (parâmetrodevops-integration-token ). Para acessar seu token secreto, navegue até o registro da ferramenta GitHub em ServiceNow (Todos > Ferramentas > Ferramentas de Orquestração) e selecione Copiar token na IU clássica.

    Fluxos de trabalho no repositório GitHub

    Crie um arquivo YAML para definir a configuração do fluxo de trabalho no repositório GitHub.

    Os seguintes pontos devem ser considerados ao definir o fluxo de trabalho:
    • Todos os fluxos de trabalho do seu repositório devem ter uma extensão de arquivo .yml ou .yaml. Todos os fluxos de trabalho devem estar no diretório .github/workflows e seguir a sintaxe definida em Sintaxe de fluxo de trabalho para ações do GitHub.

      Fluxos de trabalho na guia Ações do GitHub

    • O nome do fluxo de trabalho deve corresponder ao nome do arquivo do fluxo de trabalho.

      O nome do fluxo de trabalho deve corresponder ao nome do arquivo

    • Os nomes dos fluxos de trabalho em Todos os fluxos de trabalho na guia Ações devem corresponder aos fluxos de trabalho salvos no diretório .github/workflows do seu repositório.

      Posicionamento de arquivos de fluxo de trabalho na guia Ações

    • Um nome de exibição deve ser fornecido para cada trabalho e deve ser exclusivo para cada trabalho no fluxo de trabalho. O nome do trabalho deve corresponder ao nome da fase na ação personalizada.

      Nome do trabalho na ação personalizada

    • Use o evento workflow_dispatch para acionar um fluxo de trabalho manualmente.

      Acionamento manual de um fluxo de trabalho usando um evento

    GitHub Actions detalhes de execução do fluxo de trabalho em DevOps

    Depois de configurar os webhooks, as notificações de GitHub Actions são enviadas para ServiceNow DevOps sempre que um fluxo de trabalho é executado ou acionado.

    Os detalhes a seguir são enviados para a instância ServiceNow quando um fluxo de trabalho é executado manualmente ou acionado automaticamente em um repositório GitHub.
    • O webhook workflow_job notifica a instância ServiceNow com o status do trabalho (enfileirado, in_progress, concluído) quando o fluxo de trabalho é executado manualmente ou acionado automaticamente em um repositório GitHub.
    • Eventos de entrada são criados na instância ServiceNow para o status do trabalho (enfileirado, in_progress e concluído) e os eventos in_progress são ignorados.
    • Eventos de entrada enfileirados e concluídos são processados e ServiceNow DevOps Etapas de pipeline e Tarefas de Orquestração são criadas para trabalhos configurados no fluxo de trabalho.
    • A execução de pipeline é criada para cada execução de fluxo de trabalho com registros de execuções de tarefa e de etapa criados para cada trabalho executado na execução do fluxo de trabalho.
    • Você pode usar a IU de pipeline para visualizar interações e resultados em uma execução de pipeline.

    GitHub reexecuções

    As solicitações de mudança criadas para trabalhos GitHub serão reutilizadas se as solicitações de mudança estiverem nas fases de implementação e pós-implementação. Por exemplo, para uma execução de pipeline:
    • Se um trabalho falhar antes que a solicitação de mudança esteja na fase de implementação, a solicitação de mudança criada não será reutilizada quando os trabalhos com falha forem executados novamente.
    • Se os trabalhos com falha ou todos os trabalhos forem executados novamente, uma nova solicitação de mudança será criada.
    • Agora, se um trabalho falhar quando a solicitação de mudança estiver nas fases de implementação ou pós-implementação, a solicitação de mudança será reutilizada quando os trabalhos com falha ou todos os trabalhos forem executados novamente.
      Nota:
      Se a solicitação de mudança já estiver implementada em uma etapa anterior antes da falha do trabalho, durante as novas execuções, a execução do pipeline não será interrompida. A solicitação de mudança é considerada como já aprovada e implementada.

    Fluxos de trabalho compostos

    Para fluxos de trabalho compostos em que um fluxo de trabalho chama outro fluxo de trabalho e a etapa de mudança está no fluxo de trabalho secundário, o parâmetro job-name da etapa de mudança deve estar no formato job-name: '<parent-workflow-name> /<child-workflow-name> ' . Aqui, o espaço antes e depois da barra (/) é obrigatório.

    Figura 1. Exemplo de um parâmetro de nome de trabalho no fluxo de trabalho secundário
    Amostra de parâmetro de nome de trabalho.

    GitHub Actions limitações para Velocidade de mudança para DevOps integração

    • Os ambientesGitHub Actions e GitHub são compatíveis com o servidor GitHub Enterprise a partir da versão 3.3.
      • Para obter informações detalhadas sobre ambientes GitHub, consulte Como usar ambientes para implantação.
      • Os ambientesGitHub estão disponíveis para repositórios privados somente na nuvem GitHub Enterprise.
    • Para GitHub Organizações, use uma conta específica (com acesso às organizações necessárias) com token de acesso pessoal para integração com ServiceNow DevOps ou você também pode usar GitHub Aplicações por meio do Código de Autorização 2.0 ou JWT.

      Para a criação de ferramentas usando GitHub Apps - JWT, você deve criar uma ferramenta separada para uma organização separada.

    • Somente os resultados de verificação GitHub Actions mais recentes podem ser extraídos de uma instância para uma execução de fluxo de trabalho.
    • ServiceNow DevOps A automação de mudança que usa ação ou ambiente personalizado não é compatível com trabalhos paralelos. Para trabalhos paralelos, a carga de notificação do webhook não contém informações sobre os trabalhos executados em paralelo com um número de sequência. Devido a essa limitação, a sequência de trabalhos depende da ordem de execução retornada pela resposta da API (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs).
    • O URL de retorno de chamada para pausar e retomar a execução do fluxo de trabalho a partir da instância ServiceNow é compatível somente com o recurso GitHub Actions de Portões de implantação. No entanto, a criação de mudanças é possível por meio de portas de implantação e da ação personalizada do GitHub.
    • O usuário que cria a ferramenta GitHub na instância ServiceNow deve ser um revisor para aprovar o fluxo de trabalho para ambientes GitHub.