idea_world_labDEV JOURNAL
jueves, 25 de junio de 2026

Flujo de trabajo de revisión de PR de Qwen y registro de mejoras

Fecha de creación: 25 de junio de 2026

Propósito

Este documento registra el proceso de tomar el flujo de trabajo de revisión de PR basado en qwen-code y personalizarlo para el repositorio actual.

El objetivo principal de este trabajo no es solo que el flujo de trabajo termine con éxito, sino que los resultados de la revisión generados por Qwen se publiquen como comentarios reales en el PR de GitHub.

Antecedentes

Este repositorio también utiliza bots de revisión externos como CodeRabbit, Sourcery y Qodo. Sin embargo, se está experimentando con la incorporación del flujo de trabajo qwen-code para ejecutarlo a través de la ruta de OpenRouter y dejar una revisión basada en Qwen en cada PR.

Inicialmente se detuvo el flujo de la API de revisión de PR por problemas de costos. Posteriormente, al poder usar openai/gpt-oss-120b:free en el nivel gratuito de OpenRouter, se modificó el README para intentar nuevamente con esta ruta.

Estructura original del flujo de trabajo

Archivo objetivo:

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

Nombre original del flujo de trabajo:

🧐 Qwen Pull Request Review

Disparador principal:

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'

El trabajo estaba configurado para ejecutarse en los siguientes casos:

  • Ejecución manual con workflow_dispatch
  • Evento opened de pull_request_target cuando el autor del PR es OWNER, MEMBER o COLLABORATOR
  • Comentario de revisión del PR que contiene @qwen /review
  • Cuerpo de la revisión del PR que contiene @qwen /review

Las etapas principales del flujo de trabajo eran las siguientes:

  1. Checkout del código del PR
  2. Recolección del título, cuerpo, archivos modificados e información de diff del PR
  3. Ejecución de QwenLM/qwen-code-action
  4. Dentro del prompt, instruir a Qwen para que genere una revisión y pedir que la publique con gh pr comment

Problema observado

Se observó el flujo de trabajo en el PR #5.

PR:

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

El PR se creó correctamente y los siguientes bots respondieron.

  • CodeRabbit
  • Sourcery
  • Qodo

El flujo de trabajo Qwen también se ejecutó en el evento pull_request_target.

Ejecución observada:

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

Sin embargo, en el PR real no quedó ningún comentario de revisión de Qwen.

Al ver el registro del flujo de trabajo, Qwen escribe el contenido de la revisión pero no ejecuta la llamada real a la herramienta, y en su lugar imprime como texto una instrucción de estilo JSON de la siguiente forma.

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

El flujo de trabajo en sí fue exitoso, pero el resultado esperado por el usuario, “escribir un comentario en el PR”, no se completó.

Resumen de la causa

El problema fue la arquitectura que delegaba la escritura del comentario a Qwen.

El prompt original le indicaba a Qwen que realizara lo siguiente directamente.

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

Sin embargo, en la ejecución real Qwen no realizó esta tarea mediante una llamada a la herramienta, sino que solo imprimió la tarea como texto.

Por lo tanto, si el modelo no llama correctamente a la herramienta, aunque el workflow tenga éxito, no quedará ningún comentario en el PR.

Problema de estructura adicional verificado

La condición del job del workflow incluía el evento issue_comment.

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

Sin embargo, el disparador on: no incluía issue_comment.

Es decir, aunque se dejara un comentario @qwen /review en la conversación del PR, el flujo de trabajo no se iniciaba en absoluto.

Además, el disparador pull_request_target solo respondía a opened.

pull_request_target:
  types: ['opened']

Así que el evento synchronize, en el que se envía un nuevo commit al branch PR, no se volvió a ejecutar automáticamente.

Dirección de mejora

En lugar de delegar la redacción de comentarios en GitHub al modelo, se cambiará para que el paso de GitHub Actions sea responsable de escribir los comentarios.

Después de la mejora, la división de responsabilidades es la siguiente.

Qwen
  -> generar solo texto Markdown de revisión

GitHub Actions
  -> guardar la salida de Qwen en un archivo
  -> escribir un comentario en el PR con gh pr comment

Así, aunque Qwen imprima la llamada a la herramienta como texto, al menos en el paso del flujo de trabajo se puede recibir qwen_result y dejar un comentario.

Cambios

1. Refuerzo del disparador

Anteriormente:

pull_request_target:
  types: ['opened']

Cambio:

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

Intención:

  • Ejecutar cuando se abra un PR nuevo
  • Ejecutar cuando se vuelva a abrir un PR
  • Ejecutar cuando se suba un nuevo commit a la rama del PR
  • Ejecutar cuando se deje @qwen /review en la conversación del PR

Observaciones adicionales:

No fue suficiente solo reforzar el disparador on:. De hecho, cuando se hizo push de un nuevo commit a la rama del PR, se creó una ejecución pull_request_target, pero la condición del job todavía solo permite github.event.action == 'opened', por lo que la ejecución terminó como skipped.

Por lo tanto, la condición del job también debe modificarse como sigue.

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

2. Asignar id al paso Qwen

Cambios:

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

Intención:

Para leer la siguiente salida en el paso posterior.

steps.qwen_review.outputs.qwen_result

3. Cambiar la responsabilidad del prompt

El prompt original indicaba a Qwen que redactara archivos y escribiera comentarios de PR directamente.

Después del cambio, el prompt indica a Qwen que devuelva solo el texto Markdown de la revisión como respuesta 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.

Intención:

  • Reduce el problema de que Qwen genere JSON de llamadas a herramientas.
  • Transfiere la responsabilidad de escribir comentarios del modelo al paso del flujo de trabajo.

4. Añadir paso para publicar el valor de salida de Qwen como comentario en el PR

Paso añadido:

- 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"

Intención:

  • Si la salida de Qwen no está vacía, siempre se deja como comentario en el PR.
  • La redacción del comentario la lleva a cabo un paso determinista que usa GITHUB_TOKEN y gh pr comment.

Observaciones adicionales:

Al principio se leyó incorrectamente el nombre de la salida como steps.qwen_review.outputs.qwen_result. Al revisar el action.yml de QwenLM/qwen-code-action, se vio que dentro del composite se crea qwen_result, pero el nombre de la salida que se expone fuera de la acción es summary.

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

Así que el paso de comentario posterior debe leer steps.qwen_review.outputs.summary. Si se lee qwen_result, incluso cuando Qwen genera correctamente el cuerpo de la revisión, el paso de publicación se omite.

Precauciones

El flujo de trabajo pull_request_target se ejecuta con el archivo de flujo de trabajo de la rama base, no con el de la rama del PR.

Por lo tanto, simplemente subir una modificación del flujo de trabajo en la rama del PR no cambiará el comportamiento de pull_request_target del PR actual.

Para aplicarlo realmente, se necesita una de las siguientes opciones:

  1. Reflejar la modificación del flujo de trabajo primero en main.
  2. Luego, dejar un comentario @qwen /review en el PR o hacer push de un nuevo commit para ejecutar el flujo de trabajo actualizado.

En este trabajo, primero se reflejará la modificación del flujo de trabajo en main y luego se volverá a activar la revisión de Qwen en el PR #5 para verificar si se genera realmente el comentario.

Criterios de seguridad

En la documentación del flujo de trabajo no se deben registrar valores sensibles como la clave API, la URL del endpoint o la URL base del proveedor.

En los registros de GitHub Actions, los siguientes valores también deben estar sujetos a enmascaramiento de secretos.

OPENAI_API_KEY
OPENAI_BASE_URL
OPENAI_MODEL
GITHUB_TOKEN

El documento conserva solo el hecho del cambio de modelo y la estructura del workflow, sin registrar los valores reales de los secretos.

Conclusión actual

Lo que se confirmó con esta observación es lo siguiente:

  • La creación del PR en sí funcionó correctamente.
  • CodeRabbit, Sourcery y Qodo respondieron al PR de manera normal.
  • El workflow de Qwen también terminó con éxito en pull_request_target.
  • Sin embargo, en la estructura anterior Qwen podía generar instrucciones de llamada a herramientas como texto sin escribir realmente un comentario.
  • Por lo tanto, “éxito del workflow” y “éxito al crear el comentario del PR” deben considerarse por separado.
  • Cambiar la forma en que el paso posterior de GitHub Actions publica el valor de salida de Qwen directamente como comentario es más seguro.