Migration von GitHub Classroom auf Classroom 50

Dies ist eine alte Version des Dokuments!

Diese Seite beschreibt, was beim Umstieg einer bestehenden Klasse zu tun ist. Ein neuer Classroom von Grund auf: Einrichtung.

Solange beide Wege parallel installiert sind, laufen bei jedem Push zwei Autograder nebeneinander — der alte scheitert dabei am Moodle-Aufruf. Die Migration ist erst mit Schritt 2 abgeschlossen.

	vorher	nachher
Bewertung ausgelöst von	`.github/workflows/classroom.yml` im Studi-Repo	zentralem `autograde-runner.yaml`
Bewertungs-Logik	`BZZ-Commons/pygrader`	`BZZ-Commons/pygrader50`, per Tag gepinnt
Moodle-Übertrag	direkt aus dem Studi-Repo	nachts, zentral aus dem Config-Repo
Moodle-Token	in der Org, per `secrets: inherit` überall lesbar	nur im Config-Repo
Zuordnung zu Moodle	GitHub-Name im Moodle-Profil	unverändert, dasselbe Profilfeld
Konfigurationsdateien	`.github/autograding/`	Bundle im Config-Repo, `.github/autograding/` bleibt Fallback

Die drei Dateien unittests.json, lint.json und pylintrc behalten ihr Format. Es ist kein Umschreiben der Aufgaben nötig.

Erst wenn <CLASSROOM>/autograder.py im Config-Repo liegt, bewertet Classroom 50 überhaupt etwas — vorher liefert es überall 0/0.

Ablauf und Prüfungen: Einrichtung, Schritt 2.

.github/workflows/classroom.yml. Zwei Jobs stecken darin:

Job	Was damit passiert
`grading`	ruft den alten pygrader-Workflow — ersetzt durch Classroom 50
`copy-issues`	läuft nur unter `if: contains(github.actor, ''classroom`)'', also nur beim GitHub-Classroom-Bot; unter Classroom 50 feuert er nie

Ein separates copyissues.yml mit workflow_dispatch macht dasselbe manuell. Beim Löschen von classroom.yml geht also keine Funktion verloren.

.github/autograding/ mit unittests.json, lint.json und pylintrc — das ist der Fallback, solange nicht jede Aufgabe ein Bundle im Config-Repo hat.

requirements.txt und Hilfsskripte wie _run_pylint.py stören die Bewertung nicht: pygrader50 installiert die Studi-Abhängigkeiten bewusst nicht. Für die lokale Arbeit der Lernenden zählt die Datei trotzdem, deshalb hält sie ein eigenes Skript aktuell — siehe sync-template-pins.py.

Nicht die Repos der Template-Organisation auflisten. Dort liegen auch Templates von Modulen, die noch auf dem alten Pfad laufen — ihnen den Workflow zu nehmen, stoppt dort still die Bewertung.

Massgeblich ist der template-Block in <CLASSROOM>/assignments.json:

gh api repos/<ORG>/classroom50/contents/<CLASSROOM>/assignments.json \
   -H 'Accept: application/vnd.github.raw' \
  | jq -r '.assignments[] | "\(.template.owner)/\(.template.repo)"' | sort -u

scripts/remove-legacy-classroom-yml.sh <ORG> <CLASSROOM>            # Trockenlauf
scripts/remove-legacy-classroom-yml.sh <ORG> <CLASSROOM> --apply    # löschen

Das Skript nimmt die Liste aus 2.3 und ergänzt die bereits angenommenen Studi-Repos. Es ist wiederholbar; fehlende Dateien meldet es als absent.

Template-Änderungen erreichen bestehende Repos nicht. Ein Studi-Repo trägt seine Kopie aus dem Moment der Annahme — deshalb behandelt das Skript beide Seiten. Umgekehrt sind Repos früherer Klassen, die dasselbe Template benutzt haben, von der Template-Änderung nicht betroffen.

Sicherheitsrelevant. Der alte Workflow reichte den Moodle-Token per secrets: inherit an den Bewertungs-Workflow weiter. Jede Person mit Schreibrecht auf ein Studi-Repo konnte ihn mit drei Zeilen auslesen — und der Token kann Noten für beliebige Personen setzen.

Secret in allen betroffenen Organisationen löschen — typischerweise die Studi-Org und die Template-Org. Namen prüfen: es gibt MOODLE_TOKEN und MOODLE_TOKEN2.
Den Token in Moodle neu erzeugen und den alten invalidieren. Löschen allein beendet nur die künftige Exposition, nicht die vergangene.

gh secret list --org <ORG>

Hier ändert sich nichts: Die Lernenden tragen ihren GitHub-Namen weiterhin im Moodle-Profil ein, Feld GitHub Classroom (Anleitung). Das Plugin mod_externalassignment liest ausschliesslich dieses Feld; der Moodle-Benutzername spielt keine Rolle. Vor dem ersten echten Übertrag prüfen, ob das Feld bei allen Teilnehmenden gefüllt und richtig geschrieben ist.

Der Rest — Aktivität External Assignment, Slug als Name, Token im Config-Repo — steht unter Noten nach Moodle übertragen.