====== 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 | 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.

===== 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 =====

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 [[.: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.