Repository navigation
fix(ci): Gruppenlabel statt eines namentlich gepinnten Runners - #157
Merged
Merged
Conversation
runs-on stand an beiden Stellen auf kind-testing-runner-1 — also auf EINEM Rechner, adressiert ueber dessen runner-eigenes Label. Solange der belegt ist, wartet jeder Check hier, auch wenn baugleiche Runner idle danebenstehen. Genau das am 2026-08-21 passiert: der taegliche content-gaps-Cron in stuttgart-things/rank5 (event=schedule, 07:08:04Z) forderte das GETEILTE Label kind-testing-labda an, der Scheduler legte ihn auf runner-1, und die Checks von helm#156 blieben queued. kind-testing-runner-2 war in derselben Sekunde busy=false und traegt identische Labels. Der Pin war seinerseits schon ein Fix fuer dieses Problem — b5aaf91 (2026-07-03) schaltete um, weil ghr-helm-skyami-cicd offline war und Checks unbegrenzt haengen blieben. Getauscht wurde dabei aber nur ein Einzel-Runner gegen einen anderen, womit der Ausfallmodus erhalten blieb. Deshalb steht der Grund jetzt als Kommentar in der Datei: die naechste Queueing-Panne soll nicht wieder in einen Rechnernamen aufgeloest werden. kind-testing-labda tragen beide kind-testing-Runner. Damit nimmt der Job, wer frei ist, und ein einzelner offline gegangener Runner blockiert nichts mehr. Geprueft: gemessen ueber /orgs/stuttgart-things/actions/runners (busy-Flags und Labels) und ueber die Job-API des blockierenden Runs (runner_name=kind-testing-runner-1). YAML nachgeparst, beide Jobs loesen auf kind-testing-labda auf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0196ZK3n9XHuWxhx9es8bcTi
patrick-hermann-sva
temporarily deployed
to
k8s
August 21, 2026 07:37 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
patrick-hermann-sva
temporarily deployed
to
k8s
August 21, 2026 07:37 — with
GitHub Actions
Inactive
GitHub Actions
Inactive
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Zwei Stellen (
Analyze-Changed-Chartsundyaml-lint).Der Befund
runs-onadressierte einen einzelnen Rechner über dessen runner-eigenes Label. Solange der belegt ist, wartet jeder Check in diesem Repo — auch wenn baugleiche Runner daneben idle stehen.Heute morgen genau das, gemessen über
/orgs/stuttgart-things/actions/runners:Blockiert hat ihn ein Cron aus einem unbeteiligten Repo:
Der Job wollte also selbst nur das geteilte Label — der Scheduler hat ihn zufällig auf runner-1 gelegt. Damit hingen die Checks von #156 fest, während runner-2 in derselben Sekunde frei war.
Warum das kein Einzelfall ist
Der Pin war seinerseits schon ein Fix für dieses Problem:
Getauscht wurde ein Einzel-Runner gegen einen anderen — der Ausfallmodus blieb erhalten und hat jetzt zum zweiten Mal zugeschlagen. Deshalb steht die Begründung als Kommentar in der Datei: die nächste Queueing-Panne soll nicht wieder in einen Rechnernamen aufgelöst werden.
Wirkung
kind-testing-labdatragen beide kind-testing-Runner. Der Job nimmt, wer frei ist; ein einzelner offline gegangener Runner blockiert nichts mehr. Doppelte Kapazität, ohne neue Infrastruktur.Dieser PR validiert sich selbst: bei
pull_requestbenutzt GitHub die Workflow-Datei aus dem PR-Branch, die Checks hier laufen also bereits über das Gruppenlabel.YAML nachgeparst, beide Jobs lösen auf
kind-testing-labdaauf.🤖 Generated with Claude Code
https://claude.ai/code/session_0196ZK3n9XHuWxhx9es8bcTi