Ihre erforderlichen Statusüberprüfungen waren erfolgreich. Ihre Tests wurden nicht ausgeführt.

Unit- und E2E-Aufträge starteten erst, nachdem das Label run-tests hinzugefügt worden war. So konnten wir aufwendige Testreihen aufschieben, solange ein Pull Request noch vorbereitet wurde; vor jedem Merge sollten sie aber weiterhin laufen. Der Branchschutz erzwang diese Absicht nicht.

Wurde die Bedingung auf Auftragsebene als falsch ausgewertet, übersprang das System den Test-Worker. GitHub gab dem übersprungenen Auftrag für erforderliche Statusüberprüfungen dennoch ein erfolgreiches Ergebnis. Der Pull Request konnte daher grün erscheinen, obwohl kein Testbefehl ausgeführt worden war.

Ich behielt das Label bei, weil es während der Prüfung nützlich war. Der Fehler bestand darin, den bedingten Worker selbst zur erforderlichen Statusüberprüfung zu machen. GitHub konnte diese Überprüfung erfüllen, wenn der Worker übersprungen wurde.

unit-tests:
  if: |
    github.event_name == 'workflow_dispatch' ||
    (github.event.action == 'labeled' && github.event.label.name == 'run-tests') ||
    (github.event.action == 'synchronize' &&
      contains(github.event.pull_request.labels.*.name, 'run-tests'))
  steps:
    - run: pnpm test:unit:coverage

Der Worker entscheidet, ob er jetzt ausgeführt wird. Ein getrenntes Gate entscheidet, ob der Pull Request sicher zusammengeführt werden kann. Die Vermischung dieser Entscheidungen erzeugte den falschen grünen Zustand.

Ich fügte nach jedem Worker ein kleines Gate hinzu. Es führt den Worker unter needs auf, läuft mit if: always() und besteht nur, wenn das Worker-Ergebnis success lautet. Eine übersprungene, abgebrochene oder fehlgeschlagene Testreihe blockiert nun den Merge mit einer hilfreichen Meldung.

ci-gate:
  name: CI Gate (Unit)
  runs-on: ubuntu-latest
  needs: [unit-tests]
  if: always()
  steps:
    - name: Check test results
      run: |
        result="${{ needs.unit-tests.result }}"
        if [[ "$result" != "success" ]]; then
          echo "::error::Unit tests did not pass (result: $result)"
          exit 1
        fi
        echo "Unit tests passed"

Upstream-Ergebnis  Erforderliches Gate
success             bestanden
failure             fehlgeschlagen
cancelled           fehlgeschlagen
skipped             fehlgeschlagen mit Hinweis zum erforderlichen Label

Die Gates stehen vor echten Testreihen. Die Unit-Abdeckung umfasste 73 Jest-Dateien, erzwungene Grenzwerte und automatisch ansteigende Abdeckungsanforderungen. Playwright lief in Chromium und WebKit mit vier Workern, zwei Wiederholungen in CI und gemeinsam genutztem authentifiziertem Zustand.

Unit und E2E erhielten jeweils einen stabilen Gate-Namen. Die Branchschutzregeln können diese Namen weiterhin verlangen, selbst wenn sich die Worker-Implementierung später ändert.

Die Branchschutzregeln wurden so geändert, dass sie CI Gate (Unit) und CI Gate (E2E) statt der bedingten Worker verlangen. Damit war der Merge-Vertrag eindeutig: Eine erwartete Testreihe muss entweder erfolgreich laufen oder einen sichtbaren Fehler liefern, der erklärt, warum sie nicht lief.

• Lassen Sie aufwendige Arbeit bedingt, wenn das Repository dafür einen klaren Grund hat.
• Fassen Sie stets alle abschließenden Worker-Ergebnisse zusammen, die für die Merge-Richtlinie wichtig sind.
• Verlangen Sie in den Branchschutzregeln den stabilen Namen des Aggregators.
• Geben Sie bei übersprungener Validierung eine konkrete Handlungsanweisung aus, statt sie stillschweigend grün anzuzeigen.