Documentação do ChatGPT
Português
Contacto goolvyouyou@gmail.com

Rever pedidos de integração do GitLab com o Codex

Configure a Revisão de Código para pedidos de integração do GitLab e solicite revisões com @codex review.

Utilize a revisão de código do Codex para obter uma segunda revisão muito relevante dos pedidos de integração do GitLab. O Codex revê as diferenças do pedido de integração, segue as orientações do seu repositório e publica uma revisão de código padrão do GitLab centrada em problemas graves.

O suporte para o GitLab está em versão beta e encontra-se disponível em todos os planos do ChatGPT. A integração do Codex é executada na nuvem do Codex. Os controlos de repositório ao estilo do GitHub na aplicação para computador, como Create pull request, não estão incluídos nesta versão beta.

Antes de começar

Certifique-se de que tem:

Configurar a revisão de código do Codex

Configurar a ligação ao GitLab e a identidade de revisão do Codex

Para o GitLab.com, ligue a sua conta do GitLab no Codex depois de estabelecer ligação ao GitLab no ChatGPT. No GitLab autogerido ou Dedicated, cada revisor deve estabelecer ligação depois de o modelo do administrador do espaço de trabalho ter sido publicado.

No GitLab autogerido ou Dedicated, abra Codex Cloud → Settings → Connectors. Um administrador do espaço de trabalho pode permitir que o Codex crie uma conta de serviço ou guarde um token de acesso pessoal de uma conta de serviço existente.

Permitir que o Codex crie a conta

Em Codex Cloud → Settings → Connectors, selecione a aplicação do seu anfitrião do GitLab autogerido ou Dedicated → selecione Set up service account → Create a service account. O administrador do espaço de trabalho que concluir a configuração deve ter acesso de administrador à instância do GitLab. Escolha Selected groups ou Selected projects only, selecione onde o Codex deve operar e crie a conta. A opção de grupo concede acesso de Developer a cada grupo escolhido, herdado pelos respetivos projetos e subgrupos; a opção de projeto concede acesso de Developer apenas aos projetos individuais que escolher. O Codex criará a conta de serviço da instância ChatGPT Codex Connector com um token de acesso pessoal com o âmbito api.

Utilizar uma conta existente

No GitLab, crie ou escolha uma conta de serviço e conceda-lhe acesso de Developer apenas nos grupos ou projetos em que o Codex deve operar. Na página Service accounts, selecione a conta → Manage access tokens → Add new token para criar um token de acesso pessoal com o âmbito api e uma data de validade a pelo menos 30 dias. De volta ao Codex, escolha Use an existing service account, cole o token e selecione Save token. O token é encriptado quando é guardado e nunca volta a ser apresentado.

Gerir o token da conta de serviço

Os administradores do espaço de trabalho podem gerir a conta de serviço em Codex Cloud → Settings → Connectors. Para uma conta criada pelo Codex, os administradores podem revogar o token atual e gerar um novo. Para uma conta existente, os administradores podem substituir ou remover o token guardado no Codex e revogá-lo separadamente no GitLab, se necessário. O Codex não pode responder à atividade do GitLab enquanto não estiver configurado um token válido.

Escolher como a atividade do GitLab chega ao Codex

Criar um ambiente de projeto para tarefas de programação ou configuração específica do projeto

Em Codex Cloud → Settings → Environments, escolha o projeto do GitLab e crie um ambiente de projeto quando pretender que o Codex escreva ou execute código nesse projeto — por exemplo, para editar ficheiros, confirmar alterações ou enviar atualizações para o ramo de um pedido de integração — ou quando uma revisão depender de segredos específicos do projeto, acesso à rede ou comandos de configuração.

Para o GitLab.com, também é necessário um ambiente de projeto para ativar as revisões do Codex.

Ao criar o ambiente, ative Enable Codex activity from GitLab para instalar o webhook do projeto que envia eventos de pedidos de integração, comentários e problemas ao Codex. A criação do webhook do projeto requer acesso de Maintainer ou Owner, acesso de administrador ou uma função personalizada que possa administrar webhooks do projeto. Os webhooks assinados de projetos e grupos requerem o GitLab 19.0 ou posterior. No GitLab 19.0 autogerido, confirme que o sinalizador de funcionalidade webhook_signing_token está ativado; está ativado por predefinição e foi removido no GitLab 19.1.

Ativar a atividade para revisões do Codex em projetos de um grupo do GitLab

No GitLab autogerido ou Dedicated, os administradores do espaço de trabalho podem abrir Environments → GitLab activity → Manage groups para ativar revisões do Codex em todo um grupo e nos respetivos subgrupos. O Codex instalará um webhook de grupo que abrange os projetos de todo esse grupo. O utilizador do GitLab ligado deve ser Owner do grupo, e os webhooks de grupo requerem o GitLab Premium ou Ultimate e o GitLab 19.0 ou posterior.

A atividade de grupo ativa revisões de código, mas não cria ambientes de projeto. Para executar tarefas de programação acionadas pelo GitLab, como editar ficheiros, executar comandos, confirmar alterações ou enviar atualizações para um pedido de integração, crie um ambiente de projeto.

Configurar políticas de revisão de código

Configure as políticas de revisão de código nas definições de revisão do Codex. Escolha a política do repositório: Review my MRs, Review team MRs, Review all MRs ou Follow personal. Em seguida, escolha quando as revisões são executadas: On MR open, On every push ou Smart Trigger (Experimental). As definições do repositório podem substituir as predefinições pessoais.

Solicitar uma revisão do Codex

  1. Num comentário de um pedido de integração, mencione @codex review.
  2. Aguarde que o Codex reaja (👀) e publique uma revisão.

O Codex publica discussões e notas do GitLab no pedido de integração, tal como faria um colega de equipa. Por predefinição, as revisões solicitadas manualmente podem incluir conclusões P0, P1 e P2, enquanto as revisões automáticas se concentram em conclusões P0 e P1.

Ativar revisões automáticas

Para rever automaticamente os pedidos de integração elegíveis, ative Automatic reviews nas definições do Codex, escolha a política do repositório do GitLab e escolha um evento acionador: On MR open, On every push ou Smart Trigger (Experimental). O Codex é executado sem um comentário @codex review quando o evento do pedido de integração corresponde a essa política e a esse evento acionador.

A atividade do GitLab deve ser ativada através de um webhook de projeto ou de um webhook de um grupo antecessor. No GitLab autogerido ou Dedicated, a conta de serviço configurada também deve ter acesso para escrever no projeto. O Codex utiliza um ambiente de projeto configurado quando este existe. Se um grupo antecessor já ativar a atividade, os projetos descendentes herdam essa cobertura.

Personalizar o que o Codex revê

O Codex procura ficheiros AGENTS.md no seu repositório e segue as regras de revisão de código aplicáveis. Adicione uma secção ## Code Review Rules ao ficheiro mais próximo do código regido pelas regras. Utilize cabeçalhos ### para agrupar verificações relacionadas quando for útil.

Por exemplo, um serviço de relatórios de experiências pode impedir que o comportamento posterior à exposição altere uma coorte de comparação:

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

Coloque as regras aplicáveis a todo o repositório no AGENTS.md da raiz e as regras específicas do serviço num ficheiro aninhado, como services/experiment_reporting/AGENTS.md. O Codex aplica as orientações da raiz e as orientações mais específicas que abrangem cada ficheiro alterado, para que alterações não relacionadas não tenham de incluir contexto específico do serviço.

Comece com duas ou três regras concisas que codifiquem verificações que os revisores explicam frequentemente. Regras úteis:

  • Concentre-se em comportamentos relevantes e específicos do repositório. Descreva a restrição de compatibilidade, o limite de dados ou o efeito secundário inseguro a assinalar e por que motivo é importante.
  • Indique o procedimento seguro ou a exceção. Forneça ao Codex contexto suficiente para distinguir um problema real de um comportamento esperado.
  • Mantenha as regras delimitadas e duradouras. Prefira resultados a nomes de funções que podem mudar e coloque as orientações junto do código que regem.
  • Deixe as verificações mecânicas para a CI. Exclua das regras de revisão a formatação, o lint e outras verificações determinísticas.

Abra um pedido de integração representativo e solicite uma revisão com @codex review. Aperfeiçoe as regras com base nas conclusões e nos comentários que observar e restrinja ou remova orientações que produzam ruído.

As regras de revisão de código orientam o Codex; não substituem testes, proteções de ramos nem aprovações obrigatórias.

Para definir um foco pontual, adicione-o ao comentário do pedido de integração:

@codex review for issues in the database migration

Atuar sobre as conclusões da revisão

A correção das conclusões da revisão requer um ambiente de projeto configurado; a atividade de grupo, por si só, suporta revisões, mas não pode executar tarefas de programação. Se o projeto tiver um ambiente, peça ao Codex para corrigir um problema no mesmo pedido de integração, deixando outro comentário:

@codex fix the P1 issue

O Codex inicia uma conversa na nuvem tendo o pedido de integração como contexto e pode enviar uma correção para o ramo quando tiver permissão para o fazer.

Atribuir outras tarefas ao Codex

As outras tarefas de programação também requerem um ambiente de projeto configurado; a atividade de grupo, por si só, suporta revisões. Se mencionar @codex num comentário com qualquer conteúdo que não seja review, o Codex inicia uma conversa na nuvem utilizando o pedido de integração como contexto.

@codex fix the CI failures

Resolver problemas da revisão de código

Se o Codex não reagir nem publicar uma revisão:

  • Confirme que foi selecionada a aplicação do GitLab pretendida; se utilizar uma configuração específica do projeto, confirme que o projeto tem o ambiente de nuvem do Codex pretendido.
  • Confirme a atividade do projeto ou de um grupo antecessor. No GitLab, consulte Webhooks → Recent events e verifique se os pedidos de integração e as notas são entregues com êxito.
  • No GitLab autogerido ou Dedicated, confirme que o webhook do projeto ou grupo está assinado, que a verificação SSL está ativada e que a instância utiliza o GitLab 19.0 ou posterior. No GitLab 19.0 autogerido, confirme que o sinalizador de funcionalidade webhook_signing_token está ativado; repare os hooks desativados automaticamente após falhas.
  • No GitLab autogerido ou Dedicated, confirme que o token de acesso pessoal da conta de serviço existente está ativo e tem o âmbito api. Se o Codex tiver criado a conta de serviço, confirme que está corretamente configurada nas definições do conector do Codex e que o projeto ou grupo está ativado.
  • No GitLab autogerido ou Dedicated, confirme que a conta de serviço do espaço de trabalho — e não apenas o utilizador do GitLab ligado — tem acesso de Developer ao projeto ou a um grupo principal, para que o Codex possa publicar revisões e reações. A associação é herdada; a atividade e o acesso da conta de serviço são independentes.
  • Confirme que Code review ou Automatic reviews está ativado e que o pedido de integração corresponde à política e ao evento acionador do repositório.
  • Utilize @codex review.