idea_world_labDEV JOURNAL
quinta-feira, 25 de junho de 2026

Fluxo de Revisão de PR do Qwen e Registro de Melhorias

Data de criação: 25 de junho de 2026

Objetivo

Este documento registra o processo de trazer o workflow de revisão de PR baseado em qwen-code e personalizá‑lo para o repositório atual.

O objetivo principal deste trabalho não é apenas que o workflow termine com sucesso, mas fazer com que o resultado da revisão gerado pelo Qwen seja deixado como um comentário real no PR do GitHub.

Contexto

Este repositório também utiliza bots de revisão externos como CodeRabbit, Sourcery e Qodo. No entanto, estamos experimentando trazer separadamente o workflow qwen-code para operá‑lo via caminho OpenRouter e deixar uma revisão baseada no Qwen em cada PR.

Inicialmente, interrompemos o fluxo da API de revisão de PR de IA devido a questões de custo. Depois, como é possível usar openai/gpt-oss-120b:free no nível gratuito do OpenRouter, modificamos o README para tentar novamente por esse caminho.

Estrutura original do workflow

Arquivos alvo:

.github/workflows/qwen-code-pr-review.yml

Nome original do workflow:

🧐 Qwen Pull Request Review

Principais gatilhos:

on:
  pull_request_target:
    types: ['opened']
  pull_request_review_comment:
    types: ['created']
  pull_request_review:
    types: ['submitted']
  workflow_dispatch:
    inputs:
      pr_number:
        required: true
        type: 'number'

A condição do job estava configurada para ser executada nos seguintes casos.

  • workflow_dispatch execução manual
  • Caso o evento opened de pull_request_target e o autor do PR seja OWNER, MEMBER ou COLLABORATOR
  • Caso o comentário de revisão do PR contenha @qwen /review
  • Caso o corpo da revisão do PR contenha @qwen /review

As principais etapas do workflow foram as seguintes.

  1. checkout do código PR
  2. Coleta do título, corpo, arquivos modificados e informações de diff do PR
  3. QwenLM/qwen-code-action execução
  4. Instruir o Qwen dentro do prompt a criar uma revisão e comentar usando gh pr comment

Problemas observados

Observei o workflow na prática no PR #5.

PR:

https://github.com/yyeongjin/idea_world/pull/5

O PR foi criado normalmente e os seguintes bots responderam.

  • CodeRabbit
  • Sourcery
  • Qodo

O workflow Qwen também foi executado no evento pull_request_target.

Execução observada:

workflow: 🧐 Qwen Pull Request Review
event: pull_request_target
conclusion: success

Mas no PR real não ficou nenhum comentário de revisão do Qwen.

Ao observar o log do workflow, vemos que o Qwen escreveu o conteúdo da revisão, mas não executou a chamada real da ferramenta, e em vez disso imprimiu uma instrução no estilo JSON como texto.

{"tool":"write_file", ...}
{"tool":"run_shell_command", ...}

O workflow em si foi bem‑sucedido, mas o resultado esperado pelo usuário, “escrever um comentário no PR”, não foi concluído.

Resumo das causas

O problema foi a estrutura que delegou a escrita de comentários ao Qwen.

O prompt original instruiu o Qwen a executar o seguinte diretamente.

1. write_file("review.md", "<your detailed review feedback here>")
2. gh pr comment $PR_NUMBER --body-file review.md --repo $REPOSITORY

No entanto, na execução real, o Qwen não realizou esta tarefa por meio de chamada de ferramenta, mas apenas imprimiu o que precisava ser feito como texto.

Portanto, se o modelo não chamar a ferramenta corretamente, mesmo que o workflow tenha sucesso, nenhum comentário será deixado no PR.

Problema de estrutura adicional verificado

A condição do job do workflow incluía o evento issue_comment.

(github.event_name == 'issue_comment' && ... contains(github.event.comment.body, '@qwen /review') ...)

Mas o gatilho on: não tinha issue_comment.

Ou seja, mesmo deixando um comentário @qwen /review na conversa do PR, o workflow não era iniciado de forma alguma.

Além disso, o gatilho pull_request_target respondia apenas ao opened.

pull_request_target:
  types: ['opened']

Portanto, o evento synchronize, que ocorre quando um novo commit é enviado para a branch do PR, não foi executado automaticamente novamente.

Direção de aprimoramento

Em vez de delegar a escrita de comentários no GitHub ao modelo, alteramos para que a etapa do GitHub Actions seja responsável por escrever os comentários.

A divisão de responsabilidades após a melhoria é a seguinte:

Qwen
  -> gerar apenas texto de revisão em Markdown

GitHub Actions
  -> salvar a saída do Qwen em um arquivo
  -> escrever um comentário no PR usando gh pr comment

Assim, mesmo que o Qwen imprima a chamada de ferramenta como texto, ainda é possível receber qwen_result na etapa do workflow e deixar um comentário.

Alterações

1. Reforço do gatilho

Original:

pull_request_target:
  types: ['opened']

Alteração:

pull_request_target:
  types: ['opened', 'reopened', 'synchronize']
issue_comment:
  types: ['created']

Intenção:

  • Executar quando um PR for aberto
  • Executar quando um PR for reaberto
  • Executar quando um novo commit for adicionado ao branch do PR
  • Executar quando deixar @qwen /review na conversa do PR

Observação adicional:

Não foi suficiente apenas reforçar o gatilho on:. Na prática, quando um novo commit foi enviado ao branch do PR, a execução pull_request_target foi criada, mas a condição do job ainda permite apenas github.event.action == 'opened', portanto a execução terminou como skipped.

Portanto, a condição do job também deve ser modificada da seguinte forma.

(github.event.action == 'opened' ||
 github.event.action == 'reopened' ||
 github.event.action == 'synchronize')

2. Atribuição de id ao passo Qwen

Alteração:

- name: 'Run Qwen PR Review'
  id: 'qwen_review'

Intenção:

Para ler a próxima saída na etapa subsequente.

steps.qwen_review.outputs.qwen_result

3. Alteração de responsabilidade do prompt

O prompt original instruía o Qwen a criar arquivos e escrever comentários de PR diretamente.

Após a alteração, o prompt instrui o Qwen a retornar apenas o texto de revisão em Markdown como resposta final.

Return the review markdown text as your final answer.
Do not call write_file.
Do not call gh pr comment.
Do not output JSON tool-call instructions.
A later GitHub Actions step will post your final answer as a PR comment.

Intenção:

  • Reduzir o problema de o Qwen gerar JSON de chamada de ferramenta.
  • Transferir a responsabilidade de escrever comentários do modelo para a etapa do fluxo de trabalho.

4. Etapa adicionada para publicar o valor de saída do Qwen como comentário no PR

Etapa adicionada:

- name: 'Post Qwen PR Review'
  if: |-
    ${{ always() && steps.qwen_review.outputs.summary != '' }}
  env:
    GITHUB_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
    PR_NUMBER: '${{ steps.get_pr.outputs.pr_number || steps.get_pr_comment.outputs.pr_number }}'
    REPOSITORY: '${{ github.repository }}'
    QWEN_RESULT: '${{ steps.qwen_review.outputs.summary }}'
  run: |-
    {
      echo "## Qwen PR Review"
      echo
      printf '%s\n' "$QWEN_RESULT"
    } > qwen-review.md
    gh pr comment "$PR_NUMBER" --body-file qwen-review.md --repo "$REPOSITORY"

Intenção:

  • Se a saída do Qwen não estiver vazia, sempre deixe um comentário no PR.
  • A escrita do comentário é feita por uma etapa determinística que usa GITHUB_TOKEN e gh pr comment.

Observação adicional:

No início, o nome da saída foi lido incorretamente como steps.qwen_review.outputs.qwen_result. Ao verificar o action.yml do QwenLM/qwen-code-action, percebeu‑se que, embora a etapa interna do composite crie qwen_result, o nome da saída exposta fora da ação é summary.

outputs:
  summary:
    value: ${{ steps.qwen_run.outputs.qwen_result }}

Então o passo de comentário subsequente deve ler steps.qwen_review.outputs.summary. Se ler qwen_result, mesmo que o Qwen gere o corpo da revisão corretamente, o passo de postagem será ignorado.

Atenção

O workflow pull_request_target é executado com base no arquivo de workflow do branch base, não no arquivo de workflow do branch da PR.

Portanto, apenas enviar uma modificação do workflow no branch da PR não altera o comportamento atual de pull_request_target da PR.

Para aplicar efetivamente, é necessário um dos seguintes procedimentos:

  1. Primeiro aplicar a modificação do workflow no main.
  2. Em seguida, deixar @qwen /review na PR ou fazer um novo commit e enviá‑lo para executar o workflow alterado.

Neste trabalho, a modificação do workflow será primeiro refletida no main e, depois, será disparada novamente a revisão do Qwen na PR #5 para verificar se o comentário real é criado.

Critérios de segurança

A documentação do workflow não deve conter valores sensíveis como chave de API, URL de endpoint ou URL base do provedor.

Nos logs do GitHub Actions, esses valores também devem ser alvo de mascaramento de segredos.

OPENAI_API_KEY
OPENAI_BASE_URL
OPENAI_MODEL
GITHUB_TOKEN

O documento mantém apenas a informação de mudança de modelo e a estrutura do workflow, sem registrar os valores reais de secret.

Conclusão atual

O que foi confirmado por esta observação é o seguinte:

  • A criação do PR em si funcionou normalmente.
  • CodeRabbit, Sourcery e Qodo responderam ao PR de forma correta.
  • O workflow do Qwen também terminou com sucesso em pull_request_target.
  • Contudo, na estrutura anterior o Qwen podia gerar instruções de chamada de ferramenta como texto, sem realmente postar um comentário.
  • Portanto, “sucesso do workflow” e “sucesso na criação de comentário no PR” devem ser considerados separadamente.
  • É mais seguro alterar o passo subsequente do GitHub Actions para que o valor de saída do Qwen seja publicado diretamente como comentário.