GitLab

Abra uma issue do GitLab para cada incidente do Status200, para que o trabalho de acompanhamento fique registrado no projeto dono do serviço. Um workflow chama a API de issues do GitLab, no GitLab.com ou em um GitLab próprio.

Como funciona#

O workflow roda uma vez para cada novo incidente. O bloco API Post (JSON) dele envia o título e a descrição do incidente para as issues do projeto, assinados com um token de acesso.

Antes de começar#

• O ID do projeto do GitLab. Na página de visão geral do projeto, selecione o menu de ações, os três pontos verticais, e depois Copy project ID.
• Um token de acesso do GitLab com o escopo api, para um usuário ou bot cuja função no projeto possa criar issues: um token de acesso de projeto, de grupo ou pessoal. Crie-o em Settings → Access tokens no projeto, no grupo ou nas configurações do seu usuário.
• No Status200, permissão para criar workflows e variáveis globais. No Status200 Cloud, os workflows exigem o plano Growth ou superior.

Guardar o token#

Uma variável secreta é substituída por [REDACTED] nos logs de execução, então o token nunca aparece em uma execução.

Abrir uma issue do GitLab para cada incidente#

1. Criar o workflow#

   Vá em Fluxos de trabalho, clique em Criar fluxo de trabalho e depois em Começar do zero. Dê o nome Incidents to GitLab e clique em Criar fluxo de trabalho.

2. Adicionar o gatilho#

   Clique no bloco tracejado Choose what starts this workflow e escolha On Create Incident. Clique no gatilho: os seus Fields to pass on começam com Título, então clique em Adicionar campo e escolha Descrição e Incident Number With Prefix.

3. Abrir a issue#

   Clique em Adicionar componente, adicione um bloco API Post (JSON) e conecte a ele o ponto Success do gatilho. Defina a URL dele como https://gitlab.com/api/v4/projects/12345678/issues, com o ID do seu projeto no lugar de 12345678. Em Mais campos, defina os Request Headers dele como:

   JSON

   {
     "PRIVATE-TOKEN": "{{global.variables.GITLAB_TOKEN}}"
   }

   E o Request Body como:

   JSON

   {
     "title": "{{local.components.incident-on-create-1.returnValues.model.title}}",
     "description": "{{local.components.incident-on-create-1.returnValues.model.description}}\n\nOpened by Status200 for incident {{local.components.incident-on-create-1.returnValues.model.incidentNumberWithPrefix}}.",
     "labels": "incident,oneuptime"
   }

4. Testar e depois ativar#

   Clique em Executar fluxo de trabalho, escolha um incidente de teste em Incidente e execute. A etapa API Post (JSON) mostra uma resposta 201 com a nova issue, com o iid e o web_url dela. Depois ative Habilitado no topo do Construtor.

O bloco envia JSON, então não precisa de cabeçalho Content-Type. O GitLab cria os rótulos que ainda não conhece, então incident e oneuptime não precisam de nenhuma preparação. A issue continua aberta quando o incidente é resolvido, já que o trabalho de acompanhamento costuma durar mais que o incidente.

Dicas#

• Um GitLab próprio. Envie a requisição para o seu servidor em vez disso: https://gitlab.example.com/api/v4/projects/12345678/issues. Um servidor em um endereço de rede privado precisa de um Status200 auto-hospedado cujo administrador o permita: veja Acesso de rede para fora.
• O caminho do projeto no lugar do ID. O caminho funciona no lugar do ID, com a / escrita como %2F: projects/your-group%2Fyour-project/issues. A URL é enviada exatamente como está escrita, então codifique-a você mesmo.
• Atribua. Adicione "assignee_ids": [42] ou "due_date": "2026-12-31" ao corpo, ou "confidential": true para mostrá-la só aos membros do projeto.
• Só alguns incidentes. Coloque um bloco If / Else entre o gatilho e o bloco de API, e abra issues só no lado Yes dele, por exemplo para uma gravidade.

Solução de problemas#

A etapa API Post (JSON) segue por Error quando o GitLab recusa a requisição. O Response Status e o Response Body dela na execução dizem por quê.

Próximos passos#