Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howto:git:classroom50:migration [2026/08/18 12:21] – Sync aus BZZ-Commons/pygrader50: Moodle-Zuordnung über das Profilfeld korrigiert admin
+++ howto:git:classroom50:migration [2026/08/25 10:07] (aktuell) – Veraltet - Inhalt jetzt unter github.com/BZZ-Commons/pygrader50/docs admin
@@ Zeile 1: / Zeile 1: @@
-====== Migration von GitHub Classroom auf Classroom 50 ======
-Diese Seite beschreibt, was beim Umstieg einer bestehenden Klasse zu tun ist.
-Ein neues Klassenzimmer von Grund auf: [[.:einrichtung|Einrichtung]].
-<WRAP center round important 90%>
-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.
-</WRAP>
-===== Was sich ändert =====
-^ ^ 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.
-===== 1. Klassen-Default setzen =====
-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|Einrichtung, Schritt 2]].
-===== 2. Alten Workflow entfernen =====
-==== 2.1 Was raus muss ====
-''.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**.
-==== 2.2 Was bleiben muss ====
-''.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
-[[.:cli#scriptssync-template-pinspy_pins_aktualisieren|sync-template-pins.py]].
-==== 2.3 Die Zielliste richtig bilden ====
-<WRAP center round important 90%>
-**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.
-</WRAP>
-Massgeblich ist der ''template''-Block in ''<CLASSROOM>/assignments.json'':
-<code bash>
-gh api repos/<ORG>/classroom50/contents/<CLASSROOM>/assignments.json \
-   -H 'Accept: application/vnd.github.raw' \
-  | jq -r '.assignments[] | "\(.template.owner)/\(.template.repo)"' | sort -u
-</code>
-==== 2.4 Ausführen ====
-<code bash>
-scripts/remove-legacy-classroom-yml.sh <ORG> <CLASSROOM>            # Trockenlauf
-scripts/remove-legacy-classroom-yml.sh <ORG> <CLASSROOM> --apply    # löschen
-</code>
-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.
-===== 3. Alten Moodle-Token entwerten =====
-<WRAP center round important 90%>
-**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.
-</WRAP>
-  - 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.
-<code bash>
-gh secret list --org <ORG>
-</code>
-===== 4. Moodle-Seite umstellen =====
-Hier ändert sich **nichts**: Die Lernenden tragen ihren GitHub-Namen weiterhin
-im Moodle-Profil ein, Feld //GitHub Classroom//
-([[howto:git:github_moodle|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 [[.:moodle|Noten nach Moodle übertragen]].
-===== 5. Prüfen, dass wirklich umgestellt ist =====
-  * In einem Studi-Repo pushen: Es startet **genau ein** Bewertungslauf.
-  * Das Release zeigt eine echte Punktzahl, nicht ''0/0''.
-  * ''gh secret list --org <ORG>'' listet keinen Moodle-Token mehr.
-  * Ein ''moodle-sync''-Trockenlauf zeigt die erwarteten Personen und Punkte.