---
sourceDocument: Xanadu IT Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/xanadu/it-service-management

 Release :

    - xanadu

ft:locale :

    - pt-BR

ft:publication_title :

    - Xanadu IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# GitHub Actions configurações

# GitHub Actions configurações {#ariaid-title1}

* Versão de lançamento: Xanadu
* 
* Atualizado 1 de ago. de 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 min. de leitura

Informações de configuração em GitHub Actions, como segredos, fluxos de trabalho e limitações.

## Segredos em GitHub Actions {#github-actions-integration-with-devops__section_acb_rsz_gwb}

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](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
{#github-actions-integration-with-devops__table_i1t_zt5_h5b__entry__2}

| 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 (<kbd class="ph userinput">parâmetro devops-integration-token</kbd> ). 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. |
[ ]

{#github-actions-integration-with-devops__table_i1t_zt5_h5b}

## Fluxos de trabalho no repositório GitHub {#github-actions-integration-with-devops__section_hj5_5rk_xwb}

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](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions).

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

* 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.

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

{#github-actions-integration-with-devops__ul_mxh_zrk_xwb}

## GitHub Actions detalhes de execução do fluxo de trabalho em DevOps {#github-actions-integration-with-devops__section_q23_ftk_xwb}

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-actions-integration-with-devops__ul_n1m_q3v_h5b}

## GitHub reexecuções {#github-actions-integration-with-devops__section_exc_5pz_xbc}

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.
{#github-actions-integration-with-devops__ul_ytm_mrz_xbc}

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

## GitHub Actions limitações para Velocidade de mudança para DevOps integração {#github-actions-integration-with-devops__section_dbt_x2g_hwb}

* 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](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment).
  * Os ambientesGitHub estão disponíveis para repositórios privados somente na nuvem GitHub Enterprise.
  {#github-actions-integration-with-devops__ul_bdm_htb_3bc}
* 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.
{#github-actions-integration-with-devops__ul_th5_dgc_35b}
**Tópicos relacionados**   

*