idea_world_labDEV JOURNAL
Donnerstag, 25. Juni 2026

Qwen PR Review Workflow Struktur und Verbesserungsprotokoll

Erstellungsdatum: 25. Juni 2026

Ziel

Dieses Dokument zeichnet den Prozess auf, bei dem der auf qwen-code basierende PR‑Review‑Workflow übernommen und an das aktuelle Repository angepasst wird.

Der Kern dieser Arbeit besteht nicht nur darin, dass der Workflow erfolgreich abgeschlossen wird, sondern darin, dass die von Qwen erzeugten Review‑Ergebnisse tatsächlich als Kommentare im GitHub‑PR hinterlassen werden.

Hintergrund

Dieses Repository verwendet neben Qwen auch externe Review‑Bots wie CodeRabbit, Sourcery und Qodo. Zusätzlich wird ein separater qwen-code‑Workflow importiert, der über den OpenRouter‑Pfad läuft, und es wird experimentiert, für jedes PR eine Qwen‑basierte Review zu hinterlassen.

Anfangs wurde der AI‑PR‑Review‑API‑Prozess wegen Kostenproblemen gestoppt. Später konnte im OpenRouter‑Free‑Tier openai/gpt-oss-120b:free genutzt werden, sodass die README dahingehend angepasst wurde, diesen Pfad erneut zu versuchen.

Ursprüngliche Workflow‑Struktur

Zieldatei:

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

Ursprünglicher Workflow-Name:

🧐 Qwen Pull Request Review

Haupt‑Trigger:

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'

Der Job war so konfiguriert, dass er in den folgenden Fällen ausgeführt wird.

  • workflow_dispatch manuelle Ausführung
  • Wenn das opened‑Ereignis von pull_request_target ist und der PR‑Autor OWNER, MEMBER oder COLLABORATOR ist
  • Wenn im PR‑Review‑Kommentar @qwen /review enthalten ist
  • Wenn im PR‑Review‑Text @qwen /review enthalten ist

Der Hauptablauf des Workflows war wie folgt:

  1. PR‑Code auschecken
  2. PR‑Titel, -Body, geänderte Dateien und Diff‑Informationen sammeln
  3. QwenLM/qwen-code-action ausführen
  4. Im Prompt Qwen anweisen, ein Review zu erstellen und mit gh pr comment zu kommentieren

Beobachtete Probleme

Der Workflow wurde in PR #5 tatsächlich beobachtet.

PR:

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

Der PR wurde erfolgreich erstellt und die folgenden Bots haben reagiert.

  • CodeRabbit
  • Sourcery
  • Qodo

Der Qwen-Workflow wurde ebenfalls beim pull_request_target-Ereignis ausgeführt.

Beobachteter Lauf:

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

Aber im tatsächlichen PR blieb der Qwen-Review-Kommentar aus.

Wenn man das Workflow-Log betrachtet, schreibt Qwen den Review-Text, führt jedoch keinen eigentlichen Toolaufruf aus und gibt stattdessen eine Textausgabe in Form einer JSON‑ähnlichen Anweisung aus.

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

Das heißt, der Workflow selbst war erfolgreich, aber das vom Benutzer erwartete Ergebnis, das „PR‑Kommentar schreiben“, wurde nicht abgeschlossen.

Ursachen zusammenfassen

Das Problem lag in der Struktur, bei der das Schreiben des Kommentars Qwen überlassen wurde.

Ursprünglich wies die Eingabeaufforderung Qwen an, Folgendes direkt auszuführen.

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

In der tatsächlichen Ausführung führt Qwen diese Aufgabe jedoch nicht als Werkzeugaufruf aus, sondern gibt die auszuführende Aufgabe nur als Text aus.

Daher bleibt, wenn das Modell das Werkzeug nicht korrekt aufruft, selbst wenn der Workflow erfolgreich ist, im PR kein Kommentar zurück.

Zusätzlich festgestelltes Strukturproblem

Im Job‑Bedingungen des Workflows war das issue_comment‑Ereignis enthalten.

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

Aber im on:‑Trigger war issue_comment nicht vorhanden.

Das heißt, selbst wenn man im PR‑Conversation @qwen /review als Kommentar hinterlässt, wird der Workflow überhaupt nicht gestartet.

Außerdem reagierte der pull_request_target‑Trigger nur auf opened.

pull_request_target:
  types: ['opened']

Deshalb wurde das synchronize‑Ereignis, bei dem ein neuer Commit in den PR‑Branch gepusht wird, nicht automatisch erneut ausgeführt.

Verbesserungsrichtung

Anstatt das Schreiben von GitHub‑Kommentaren dem Modell zu überlassen, wird der GitHub Actions‑Step dafür verantwortlich gemacht.

Die Aufgabenteilung nach der Verbesserung sieht wie folgt aus:

Qwen
  -> Nur den Review‑Markdown‑Text erzeugen

GitHub Actions
  -> Qwen‑Ausgabewert in einer Datei speichern
  -> Mit gh pr comment einen Kommentar zum PR hinzufügen

Auf diese Weise kann man, selbst wenn Qwen den Werkzeugaufruf als Text ausgibt, zumindest im Workflow‑Schritt qwen_result erhalten und einen Kommentar hinterlassen.

Änderungen

1. trigger Verstärkung

Vorhanden:

pull_request_target:
  types: ['opened']

Änderung:

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

Zweck:

  • Ausführen, wenn ein PR neu geöffnet wird
  • Ausführen, wenn ein PR erneut geöffnet wird
  • Ausführen, wenn ein neuer Commit zum PR‑Branch hinzugefügt wird
  • Ausführen, wenn im PR‑Conversation @qwen /review hinterlassen wird

Zusätzliche Beobachtung:

Nur das on:‑Trigger zu erweitern war nicht ausreichend. Tatsächlich wurde beim Push eines neuen Commits zum PR‑Branch ein pull_request_target‑Run erstellt, aber die Job‑Bedingung erlaubte noch nur github.event.action == 'opened', sodass der Run mit skipped endete.

Daher muss die Job‑Bedingung ebenfalls wie folgt angepasst werden.

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

2. Qwen-Schritt eine ID zuweisen

Änderung:

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

Absicht:

Um im nachfolgenden Schritt die nächste Ausgabe zu lesen.

steps.qwen_review.outputs.qwen_result

3. prompt Verantwortungsänderung

Die ursprüngliche Eingabeaufforderung wies Qwen an, Dateien zu erstellen und PR-Kommentare direkt zu schreiben.

Nach der Änderung weist die Eingabeaufforderung Qwen an, nur den Review‑Markdown‑Text als endgültige Antwort zurückzugeben.

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.

Absicht:

  • Reduziert das Problem, dass Qwen JSON für Werkzeugaufrufe ausgibt.
  • Verlegt die Verantwortung für das Schreiben von Kommentaren vom Modell auf den Workflow‑Schritt.

4. Schritt zum Veröffentlichen von Qwen‑Ausgaben als PR‑Kommentar hinzufügen

Hinzugefügter Schritt:

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

Absicht:

  • Wenn die Qwen‑Ausgabe nicht leer ist, wird sie immer als PR‑Kommentar hinterlassen.
  • Das Schreiben des Kommentars übernimmt ein deterministischer Schritt, der GITHUB_TOKEN und gh pr comment verwendet.

Weitere Beobachtungen:

Am Anfang wurde der Ausgabenname fälschlicherweise als steps.qwen_review.outputs.qwen_result gelesen. Beim Blick in die action.yml von QwenLM/qwen-code-action stellt sich heraus, dass der Composite‑Step intern qwen_result erzeugt, der nach außen veröffentlichte Ausgabenname jedoch summary lautet.

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

So the following comment step must read steps.qwen_review.outputs.summary. If you read qwen_result, even when Qwen generates the review body correctly, the post step will be skipped.

Hinweis

Der pull_request_target‑Workflow wird nicht anhand der Workflow‑Datei im PR‑Branch, sondern anhand der Workflow‑Datei im Basis‑Branch ausgeführt.

Deshalb ändert das bloße Hochladen einer Workflow‑Änderung in den PR‑Branch das Verhalten von pull_request_target für den aktuellen PR nicht.

Um die Änderung tatsächlich wirksam zu machen, ist eines der folgenden Vorgehen nötig:

  1. Die Workflow‑Änderung zuerst in main übernehmen.
  2. Im nächsten PR @qwen /review hinterlassen oder einen neuen Commit pushen, um den geänderten Workflow auszuführen.

In diesem Vorgang wird die Workflow‑Änderung zunächst in main übernommen und dann in PR #5 erneut ein Qwen‑Review ausgelöst, um zu prüfen, ob tatsächlich ein Kommentar erstellt wird.

Sicherheitsrichtlinien

In der Workflow‑Dokumentation dürfen keine sensiblen Werte wie API‑Schlüssel, Endpunkt‑URL oder Basis‑URL des Anbieters gespeichert werden.

Auch in den GitHub‑Actions‑Logs müssen die folgenden Werte maskiert werden.

OPENAI_API_KEY
OPENAI_BASE_URL
OPENAI_MODEL
GITHUB_TOKEN

Im Dokument werden nur die Modelländerung und die Workflow‑Struktur belassen, die tatsächlichen Secret‑Werte werden nicht aufgezeichnet.

Aktuelle Schlussfolgerung

Folgendes wurde durch diese Beobachtung bestätigt:

  • Das Erstellen des PRs funktionierte einwandfrei.

  • CodeRabbit, Sourcery und Qodo reagierten normal auf den PR.

  • Der Qwen-Workflow endete ebenfalls erfolgreich bei pull_request_target.

  • Im bestehenden Aufbau konnte Qwen jedoch Anweisungen zum Aufrufen von Werkzeugen als Text ausgeben, ohne tatsächlich einen Kommentar zu schreiben.

  • Daher müssen “workflow Erfolg” und “PR‑Kommentar‑Erstellung Erfolg” separat betrachtet werden.

  • Es ist sicherer, den Ausgabewert von Qwen so zu ändern, dass der nachfolgende Schritt von GitHub Actions ihn direkt als Kommentar veröffentlicht.