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 neues Klassenzimmer 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	Moodle-Benutzername = GitHub-Login
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 nicht, werden aber nicht mehr benutzt: pygrader50 installiert die Studi-Abhängigkeiten bewusst nicht.

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>

Unter GitHub Classroom trugen die Lernenden ihren GitHub-Namen im Moodle-Profil ein. Classroom 50 vergleicht stattdessen direkt Moodle-Benutzername und GitHub-Login. Vor dem ersten echten Übertrag prüfen, ob das für alle Teilnehmenden zutrifft.

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