programmiermethoden-campusminden / deploy-to-grading Goto Github PK

Siehe https://github.com/PM-Dungeon/PM-Lecture/issues/465#issuecomment-1179278330

Für ein POC alles für EIN Repo

• Einlesen der Abgefristen

Pro Task:

• Den jeweils letzten Commit vor der Abgabefrist auschecken
• Programmiermethoden/deploy-to-abgabe#1
• Programmiermethoden/vorgabe-dummy#9
• Prüfen welche Studierende an der Lösung (vor Abgabedatum) mitgearbeitet haben
• Punkte den Studierenden zuschreiben
• Ergebnisse Ausgeben

Am Ende des Skriptes:

• Map Student:Task:Punkte ausgeben

Ein Lokales Skript analog zu der GitHub-Action erstellen.

Das bedeutet

• auschecken der Vorgaben parallel zum Repo-Dir
• Starten des Python Skripts

In diesem Repository muss das D2G System eingebunden werden.

• Dafür muss das System aber erst als github-docker-action umgesetzt werden.

(Neues Issue durch Aufteilung von #35.)

Skript zum Einlesen der YAML-Dateien assignment.yml und task.yml.

Konkretes:

Workshop "Automatische Bewertung von Programmieraufgaben" (Deutschland) (h-Index: Nichts gefunden)

Einreichfrist: 15. Juni 2023 12:00 Uhr
Workshop: 12.-13. Oktober 2023

Weiteres:

ACM/SIGCSE conference on Innovation and Technology in Computer Science Education (ITiCSE) (Europa) (h-Index: 32)
SIGCSE Technical Symposium (USA) (h-Index: 24 (Irgendwie kann ich mir nicht vorstellen, dass der Europäische besser sein soll. Dieses Symposium ist laut SIGCSE größer.)

Bereits zu spät für beides, aber unter SIGCSE habe ich schon ein paar Paper zum Thema AutoGrader gesehen. Für ITiCSE 2024 könnte die nächste Deadline im Januar 2024 sein, habe aber noch nicht genaueres gefunden.

IEEE Transactions on Learning Technologies (h-Index: 52)

Als Alternative noch ein Journal.

Implementierung der in der Dokumentation beschriebenen Metrik für CLI-Tests.

Konzeptaufgaben

• Metriken wie Spotbugs, Checkstyle und co.
• Testfälle (JUnit, Mockito, Behavior-Driven Development mit Spock/Cucumba?, Nelson)
• Toolchain welche die Ergebnisse der Metrik-Analyse und Tests zusammenfasst und Punkte verteilt.
• 1-2 Aufgaben als pok umbauen.

Dungeon

• Metriken wie Spotbugs, Checkstyle, Test-Coverage und co. (40%)
• (Kreative) Umsetzung der Aufgaben (60%)
• Abgabemodus überdenken (alla Nelson)

Vorgaben

• Im Vorgabe-Repo sind die Aufgaben (Markdown), Tests und Vorgaben (Code).
  • Pro Task ein eigenes Verzeichnis
  • Jeder Task hat ein eigenes Gradle-Skript
• Es gibt eine YAML- oder Json-Datei, in der zu jedem Task das Abgabedatum eingetragen ist
  • Eventuell das data/schedule.yaml im Lecture-Repo auslesen?! Dort stehen die Daten sowieso ...
  • Alternativ entsprechende Tabelle im Lecture-Repo
• Im Vorgabe-Repo liegen auch die Skripte für die CI sowie Konfigurationsdateien
• Wir legen vom Vorgabe Repo ein Fork für jedes Team an
• Jedes Team bekommt zusätzlich ein Dungeon-Repo mit der CI
  • Dungeon-Repo bekommt auch einen Ordner mit den Dungeon-Tasks (Markdown)
  • CI-Skripte analog zu Vorgabe-Repo

Abgaben

• Die Studierenden lösen die Aufgaben in ihren Repos und mergen die Lösungen in ihren Master.
• Die CI und das Bewertungs-Skript im Studi-Repo dient als Orientierung für die Studierenden.
  • Wird automatisch bei jedem Merge in den Master ausgeführt
  • Kann manuell ausgeführt werden
  • Gibt eine Übersicht über die Tasks, die beteiligten User und den jeweiligen Score aus
• Wir führen am Ende des Semesters das selbe Bewertungs-Skript für alle Repos (lokal) aus

Skript für die Bewertung

• Am Ende des Semsters führen wir die Bewertung durch
• Dafür checkt ein separates Skript alle Studi-Repos lokal aus. Dafür wird eine Liste mit allen Repos geführt.
• Das Bewertungs-Skript läuft über alle ausgecheckten Studi-Repos und führt darin die CI-Skripte lokal aus:
  • Checkout des Studis-Repos in lokalen Ordner (über GH-Action, nur in CI für Studi-Repo)
  • Checkout des Vorgabe-Repos in separaten lokalen Ordner (direkt über Git-Befehl)
  • Vergleich der relevanten Ordner zw. Vorgabe-Repo und Studi-Repo (Diff in Konsole)
  • In jedem Repo wird für jeden Task der letzte Commit vor der Abgabefrist des Tasks ausgechecked und die Toolchain gestartet (JUnit, Nelson, Spotbugs, Spotless, Checkstyle etc.)
    • Für Tests: Konfiguration der relevanten Ordner in Vorgabe-Repo und Studi-Repo als Source-Ordner (Gradle) => Tests werden aus dem Vorgabe-Repo genommen, Lösung aus dem Studi-Repo
    • Code-Qualität wird nur über die relevanten Ordner im Studi-Repo berechnet
    • Ergebnis: Sammlung von XML-Dateien pro Studi-Repo und Task
  • Das Skript muss prüfen, wer an der Abgabe beteiligt war:
    • Usernamen sammeln für alle Commits im jeweiligen Zeitfenster (Start bis Deadline), die den Task-Ordner betreffen
    • "Sign off"-Commit für alle, die nicht inhaltlich beigetragen haben?
    • Ergebnis: Liste mit Usernamen, die im Zeitfenster zum Task beigetragen haben
• Die Ergebnisse der Tools müssen eingesammelt werden
  • XML-Files (JUnit, Checkstyle, ...) einlesen, parsen, Ergebnisse sammeln
  • Ergebnisse in Score überführen
  • Für jeden Task: Map aus beteiligten User und Score für den Task
  • Gesamt: Summe für jeden User und die jeweiligen Punkte berechnen
• Am Ende die Liste mit den Studierenden und deren Punkte abspeichern.
  • Schlüssel: Username (GH/GL) vs. realer Studi
• Für das Dungeon ist der Ablauf ähnlich
  • Nur haben wir dafür keine Tests (also nur Code-Qualität)
  • Score wochenweise über die veränderten Ordner berechnen (=> damit können die Studis nacharbeiten und werden nur einmal bestraft, wenn sie in einer Aufgabe die Code-Qualität nicht einhalten)

Sonstiges

• Team-Repos (Konzept, Dungeon) liegen in der Organisation, Sichtbarkeit: private
• Team-Repos (Konzept, Dungeon) manuell einrichten
• Wir müssen Teamwechsel manuell durchführen
• Schauen wie man das in eine GitHub Action einbinden kann

hängt mit Dungeon-CampusMinden/Dungeon#335 zusammen

Nach Arnold Pears

Nach Petri Ihantola

Nach Thomas Staubitz

Abgrenzung von anderen AutoGradern

Durch die folgenden Punkte können wir uns von anderen AutoGradern abgrenzen:

• Integration von Git in den Arbeits-Workflow
• Serverseitige Evaluation der Abgaben ohne eigene Serverstruktur
• Gedacht für die fortgeschrittene Programmierausbildung
  • Erfordert Kenntnisse über Git und die Arbeit mit IDEs
• Vorteile von IDEs nutzbar machen gegenüber Texteingabefelder auf einer Webseite
• Wegen des Git-Workflows können wir kein ProFormA 2.0 verwenden
  • Das ist eher eine Einschränkung als Abgrenzung. Aber im Hinblick auf ABP 2023 relevant
• (Hier darf gerne ergänzt werden.)

Aus dem ABP 2023-Paper:

"Den in der CI/CD-Pipeline genutzten Docker-Container können Lehrende lokal ausführen und so die Ergebnisse aller Studierenden datenschutzgerecht einsammeln und auswerten. Dazu wird dem Container eine aus dem LMS heruntergeladene Liste mit PR-URLs übergeben. Über die GitHub-API werden anschließend die Ergebnisse der PRs der Studierenden eingesammelt. Alternativ ist es auch möglich, das Deploy-to-Grading erneut lokal auszuführen. Dies ist notwendig, wenn die Verfügbarkeit eines Artefakts abgelaufen ist. Zusätzlich kann eine Plagiatsprüfung durchgeführt werden. Abschließend wird eine csv-Datei mit den Punkten generiert, welche zurück in das LMS überführt werden muss."

Übersicht

Das Deploy-to-Grading, welches Studierende über die GitHub Action ausführen, soll von Lehrenden auch lokal in einem Docker Container zur Sammlung der Ergebnisse ausgeführt werden können. Zur Zusammenführung von ILIAS- und GitHub-Daten geben Studierende im ILIAS die URL zu ihrem Pull Request ab.

Aus dem ILIAS kann von Lehrenden folgende Liste heruntergeladen werden:

student,pr
ILIAS_NAME,PR_URL

Hinweis 1: Da ich gerade nicht weiß, wie bei ILIAS die Ergebnisse bei Textabgaben aussehen, habe ich jetzt vereinfacht eine csv-Datei angenommen.

Hinweis 2: In der csv-Datei fehlt aktuell noch die Zuordnung ILIAS-Name <-> GitHub-Username. Da müsste geprüft werden, was ILIAS für Möglichkeiten hierfür bietet. Alternativ wäre eine "Abgabe" des GitHub-Usernames zu Beginn des Semesters möglich.

Ablauf

Im Folgenden wird der D2G-Ablauf für Lehrende beschrieben:

Unvollständige Liste an Inspirationen für D2G:

• JGrade
• Code FREAK
• Gradescope Autograders
• Artemis
• CodeOcean/CodeHarbour
• JACK
• ASB
• Praktomat
• GitHub Autograding

Weitere siehe hier und hier.

Außerdem braucht es dann noch ein Skript für Cagix, welches eine Liste mit allen Repos einliest, den Workflow für jedes Repo ausführt und am Ende eine Datei ausgibt, in der jeder Studi mit seinen insgesamt erreichten Punkten drinnen steht.
@cagix Formatierungswünsche für diese Datei?

_Originally posted by @AMatutat in https://github.com/Programmiermethoden/vorgabe-dummy/issues/8

Vergleich Docker vs Cmd-based

Zusammenfassung: Auch wenn in der Tabelle mehr Vorteile für eine Cmd-basierte Action genannt sind, ist der aktuelle Favorit von mir die Docker-basierte Action, da sie flexiber ist. Ein deutlicher Nachteil der Docker-basierten Action ist der Overhead und damit die längere Ausführungszeit. Ob es im Hinblick auf das verfügbare Zeitkontingent (2.000 min/Monat auf Linux für GitHub Free) Probleme geben könnte, muss während der Implementierung geprüft werden.

Ablauf in der GH-Action

Im folgenden wird der Ablauf der GH-Action beschrieben:

Format der result.yml

task:                 # Name der Aufgabe für eine eindeutige Zuordnung
students:             # Liste mit Git-Namen der Studierenden, die an der Aufgabe beteiligt waren
tests:                # Metriken, die bei dieser Aufgabe ausgeführt wurden
  junit:
    mistakes:         # Auflistung aller Fehler innerhalb dieser Metrik
      - deduction:    # Anzahl Punkte, die für den Fehler abgezogen wurden
        description:  # Beschreibung des Fehlers
    points:           # Anzahl Punkte, die bei dieser Metrik erreicht wurden
    max_points:       # Maximal erreichbare Punktzahl (Hier notwendig für Vergabestrategie wie bei JUnit)

Bei der Ausgabe für Studierende wird unterschieden zwischen einer einfachen Ausgabe über die Konsole der GH-Action und einer webbasierten Ergebnispräsentation.

Einfache Ergebnisausgabe für Studis

Als erste Präsentation der Ergebnisse soll eine einfache Ausgabe auf der Konsole des Workflows herhalten. Dazu gehört die Präsentation der Fehler, für die Punkte abgezogen wurden und am Ende eine Übersicht über die erreichte Punktzahl.

Die Ausgabe von Fehlern sieht folgendermaßen aus:

[TESTKLASSE (ABZUG)] KURZE_BESCHREIBUNG_DES_FEHLERS

Beispiel:

[JUnit (-1 Punkt)] Test `testSetVelocityNegative()` fehlgeschlagen.

Anmerkung: Eine detailliertere Ausgabe der Fehler soll durch eine lokale Ausführung mit gradle möglich sein.

Die Zusammenfassung sieht dann folgendermaßen aus:

Aufgabenblatt: NAME
Abgabedatum: DATUM
Beteiligte Studis: LIST_STUDIS
Erreichte Gesamtpunktzahl: P/ALL

|-----------|--------|
|  Aufgabe  | Punkte |
|-----------|--------|
| Aufgabe 1 |     19 |
| Aufgabe 2 |     10 |
|    ...    |      . |
|-----------|--------|

Erklärungen:

• NAME: Name des Aufgabenblattes
• DATUM: Abgabedatum
• LIST_STUDIS: Liste der Studierenden, die mindestens einmal für diese Abgabe committed haben
• P: Erreichte Punktzahl
• ALL: Maximal erreichbare Punktzahl

Anmerkung: Die Formatierung der Tabelle kann in der finalen Implementierung anders ausehen.

Webbasierte Ergebnispräsentation für Studis (Optional)

Da bei der konsolenbasierten Ausgabe die Übersicht wahrscheinlich nicht wirklich gut sein wird, ist eine zweite Ausgabevariante sinnvoll, die insbesondere bei der Ausgabe der einzelnen Fehler hilfreicher sein soll. Im Allgemeinen ist die Idee vergleichbar zu der Übersicht von JPlag. Auf einer über GitHub.io gehosteten Webseite können Studierende ihre Ergebnisse in Form eines zip-Archivs hochgeladen. Dieses Archiv wird in Frontend verarbeitet und die Informationen daraus dargestellt.

Das zip-Archiv wird von der GH-Action als Artefakt (GH-Action) zur Verfügung gestellt und kann von GitHub heruntergeladen und auf die Webseite hochgeladen werden. Es enthält eine Zusammenfassung der Ergebnisse sowie die Aufgaben- und Aufgabenblattdefinitionen und die Ausgaben der einzelnen Tests (JUnit, Checkstyle, ...).

• Spotless auf den Task Ordner im Studi-Reo ausführen
• Gradle Task erstellen

Für den erfolgreichen Abschluss des Projekts, soll zum vorhandene Deploy-to-Abgabe System eine (präsentierbare) Demo gebastelt werden.
Das bedeutet:

• das System für EINE konkrete Aufgabe aufsetzen
• ggf. vorhandene. Bugs fixen
  • hier muss ich mal über die offenen Issues gehen
• beispiel Abgaben für die verschiedenen Szenarien
  • fehlerfrei
  • kleine Fehler
  • abgabe nach Deadline
  • manipulierte Abgabe

@cagix Ich würde das gerne getrennt von den ganzen anderen Repos halten. Also einen mini Kosmos für die D2A-Demo.
Grob skizziert stelle ich mir das so vor:

D2A-Demo-Vorgabe-Repo

• Aufgabentext und Vorgaben
• D2A Skripte, Toolchain etc.

D2A-Demo-Studi-Repo

• "Fork" des Dummy-Demo-Vorgabe-Repo
• Unterschiedliche Branches für die oben genannten Szenarien (simulieren verschiedene Abgabe-Gruppen)
• PR in den eigenen Master als Abgabe -> CI läuft

Implementierung der in der Dokumentation beschriebenen Metrik für die Plagiatserkennung. Setzt die Umsetzung (Issue #44) für die Nutzung durch Lehrende voraus.

Alle Aufgaben müssen so umformuliert werden, dass sie mit der neuen Struktur zur gewollten Lösung führen.

Gemäß der Definition in der Dokumentation sollen die Ergebnisse für alle Metriken einer Task in einer result.yml zusammengefasst werden.

Alle Aufgaben-Projekte sollen automatisch eingelesen werden.

In Gradle müssen die Subprojekte in settings.gradle hinterlegt werden. Damit wir diese Liste nicht manuell pflegen müssen, sollten diese automatisch eingelesen werden.

Ein Rahmenskript soll gemäß des dokumentierten Ablaufs Subskripte anstoßen.

Aktuell ist die Formatierung mehr oder weniger immer IntelliJ Formatierung.
Es wäre glaube ich schlau, die Formatierung vom PM-Dungeon auch auf das Homework-Solutions anzuwenden.

Es soll eine Metrik implementiert werden, mit der überprüft werden kann, ob ein Pull Request korrekt erstellt wurde. Dazu gehören unter anderem die folgenden Punkte

• Korrekte Beschreibung des Commits
  • Sinnvoller Titel
  • Sinnvolle und ausführliche Beschreibung
  • Metadaten korrekt gesetzt (Assignees, Labels, ...)
• Sauberer Inhalt des Commits
  • Commits sinnvolll gegliedert
  • Nur für den PR relevante Änderungen im Commit enthalten

Je nachdem wie tief man in das Thema einsteigen möchte, könnten auch LLMs zur Analyse der PR-Beschreibung genutzt werden.

Siehe dazu auch die Beschreibungen in der Design Dokumentation.

Die finale Rückmeldung an Lehrende sollte eine einfach weiterzuverarbeitende results.csv-Datei im folgenden Format sein:

name,mat_number,usernames,repository,no_commits,grade,overall_points,assignment1,assignment2,...
Max Mustermann,123456,mustermax;mmuster3000,https://github.com/mustermax/tasks,0,1.7,176,40,38,...

Anmerkung: Je nachdem, was präferiert wird, können wir auch Semikolons statt Kommata nutzen.

Erklärungen:

• name: Vollständiger Name des/der Studierenden
• mat_number: (optional?) Matrikelnummer des/der Studierenden
• usernames: Liste an GitHub-Benutzernamen, die von dem/der Studierenden verwendet werden
• repository: Repository, an dem mitgearbeitet wurde (Im Falle von Gruppenwechseln bräuchten wir hier eine Liste)
• no_commits: Anzahl an Aufgabenblättern, an denen nicht aktiv mitgearbeitet/mitcommitet wurde
  • Notiz: Hier muss noch definiert werden, ob die Punktzahl trotzdem zu der Gesamtpunktzahl gerechnet wird oder nicht.
• grade: (optional) Note für das Praktikum
• overall_points: Gesamtpunktzahl für alle Aufgabenblätter zusammen
• assignment1,assignment2,...: Punkte für die einzelnen Aufgabenblätter

Anmerkung: Statt oder zusätzlich zu name könnte der ILIAS-Name oder die E-Mail-Adresse angegeben werden.

Für eine detailliertere Übersicht über die Punktzahlen einzelner Studierenden existiert für jede Person noch eine eigene {firstname_lastname_mat_number}.csv-Datei (z.B. max_mustermann_123456.csv).

assignment,usernames,repository,has_commit,overall_points,task1,task2,...
Aufgabenblatt 1,mustermax,https://github.com/mustermax/tasks,true,40,10,10,...

Erklärungen:

• assignment: Name des Aufgabenblattes
• usernames: Liste an GitHub-Benutzernamen, die von dem/der Studierenden für dieses Aufgabenblatt verwendet wurden
• repository: Repository, in dem das Aufgabenblatt abgegeben wurde
• has_commit: true/false. Zeigt an, ob aktiv an der Aufgabe mitgearbeitet wurde
• overall_points: Gesamtpunktzahl für das Aufgabenblatt
• task1,task2,...: Punkte für die einzelnen Aufgaben

Je nachdem, ob die finale Bewertung als GH-Action oder lokal ausgeführt wird, wird entweder ein Ordner results mit den Dateien erstellt oder dieser wird in einer results.zip verpackt und als Artefakt in der GH-Action hochgeladen.

In einem Archiv {firstname_lastname_mat_number}/ (z.B. max_mustermann_123456/) werden die Ergebnisse einzelner Aufgabenblätter in .zip-Archiven gespeichert, sodass sie in der webbasierten Ergebnispräsentation für Studis (siehe #16) angesehen werden können.

okay hier einmal ein "schnell" runtegeschriebenes How to:

(report_folder)
  Konzeptaufgaben_name
    checkstyle
      main.html
      main.xml
      test.html
      test.xml
    junit
      html
        ...
        index.html
      xml
        TEST-...xml
        ...
    spotbugs
      main.html
      main.xml
      test.html
      test.xml

@AMatutat

Originally posted by @AHeinisch in https://github.com/Programmiermethoden/Homework-Solutions/issues/55#issuecomment-1195345499

Es sollte zuerst eine Minimalversion entwickelt werden, auf der aufbauend neue Features implementiert werden können.

Folgende Funktionen sollte die Minimalversion unterstützen:

• Ausführen des Programms für Studierende (Noch nicht für Lehrende)
• Einlesen von yaml-Dateien
• Ausführen und Auswerten der Tests und Speichern der Ergebnisse im results-Ordner (Noch keine Ergebnispräsentation)
• Metriken: Nur die compile-Metric

Für den zu implementierenden Code sollen existieren:

• Der Programmcode selbst
• JavaDoc
• Dokumentation im docs-Ordner
• Unittests

Umsetzung der Konzepte in #1 und #2.

Implementierung der in der Dokumentation beschriebenen Metrik für Unittests.

Jede Aufgabe stellt ein eigenes vollständiges Java-Projekt mit folgendem Aufbau dar (Basiert zum Teil auf Link):

taskX/
|__.config/
|  |__task.yml            # Konfiguration der Aufgabe für D2A
|  |__checkstyle.xml
|  |__(Sonstige Konfigurationen)
|__.editorconfig
|__gradle/wrapper         # Wenn nicht anderweitig auslagerbar
|__src/
|__loesung/               # Notwendig?
|__test/
|__README.md              # Aufgabenstellung
|__build.gradle
|__(Restliche Gradle-Dateien)

Das Vorgaben-Repo enthält dann auf obersten Ebene die taskX-Ordner.

Anmerkung: Zur genauen Definition der task.yml siehe #14.
Anmerkung: Es sollte noch geprüft werden, ob Gradle-Standardsachen aus den Aufgaben ausgelagert werden können.

Die gesamte Toolchain soll als github-docker-action umgesetzt werden, um eine einfache Einbindung in Workflows zu ermöglichen.

Vorhaben muss auf Machbarkeit geprüft werden.
Sind ggf. Umstrukturierungen nötig?

Anmerkung: Basierend auf Kommentar von @AMatutat.

Anmerkung: Die Namen der Repositories sind nicht final.

Notiz: Für Informationen zu git filter-repo siehe hier.

Gegenüberstellung HomeworkSolution vs SampleSolution

Zusammenfassung: Der Ansatz SampleSolution erscheint mir deutlich simpler und ermöglicht zusätzliche Aufgabentypen und Testmöglichkeiten. HomeworkSolution vereinfacht dagegen die Erstellung von neuen Aufgaben und wir haben bereits einen PR dazu.

Erläuterung Task-Repository

Studierenden wird pro Praktikumseinheit eine ausgewählte Liste an Aufgaben gestellt. Da im Template-Repository aber alle Vorlagen vorhanden sind, wird ein "Zwischenrepository" benötigt, welches Aufgaben zu Praktikumseinheiten zuordnet, die an Studierende verteilt werden. Möglicher Aufbau des Repos: Zum Beispiel pro Praktikumseinheit ein Branch oder Aktualisieren bei jedem Aufgabenbeginn oder Praktikumseinheiten aufgeteilt in Unterordner.

Anmerkung: Die Erläuterung basiert darauf, dass ich nicht weiß, wie die Aufgaben vorher an Studierende gegeben wurden.

Anmerkung 2: @AMatutat hat mir mittlerweile gesagt, dass ihr im letzten Semester den Studis alle Aufgaben auf einmal zur Verfügung gestellt habt.

@cagix @AMatutat Hat sich einer von euch schon einmal mit dem Autograding von GitHub Education befasst? Deren Umsetzung klingt stark nach unserer Idee, wenn auch mit einigen Einschränkungen möglicherweise.

Im Hinblick auf Paper sollten wir uns davon auf jeden Fall abgrenzen können.

Aus dem alten Konzept existiert eine task.json, in der die zu bewertenden Aufgaben aufgelistet sind. Ich bin der Meinung, dass wir auch nicht um eine solche Konfigurationsdatei herumkommen. Daher im folgenden mein Vorschlag.

Im folgenden unterscheide ich zwischen einer Definition für das Aufgabenblatt und für die einzelnen Aufgaben. Während die Aufgabenblattdefinition die Auswahl an Aufgaben und das Abgabedatum angibt, befindet sich in der Aufgabendefinition die eigentliche Konfiguration zum Testen und Bewerten.

Alternative: Könnten uns hier oder hier dran orientieren oder das sogar einhalten. Im zweiten Fall tun wir das schon zum Teil.

Format Aufgabenblattdefinition (assignment.yml)

name:                  # Name des Aufgabenblatts
description:           # (optional) Pfad zu einer README, falls man daraus mal richtige Aufgabenblätter generieren möchte oder direkt hier
due_date:              # Abgabetermin (Commits danach zählen nicht mehr) (Muss jedes Semester aktualisiert werden)
tasks:                 # Liste mit allen zu dem Aufgabenblatt gehörenden Aufgaben (Würde entfallen bei Zwischen-Repository)
    - (List)

Notiz: Könnte das Abgabedatum auch aus der schedule.yaml aus PM-Lecture gelesen werden?

Format Aufgabendefinition (task.yml)

name:                  # Name der Aufgabe (nötig?)
description:           # (optional) Sollte immer zur README.md zeigen
metrics:                 # Liste an Tests, die für die Benotung ausgeführt werden sollen
    compile:
        # Individuelle Konfiguration des Tests (Unvollständige Auflistung)
        points:        # siehe [Strategie der Punktevergabe](#strategie-der-punktevergabe)
    junit:
        # Individuelle Konfiguration des Tests (Unvollständige Auflistung)
        points_per_test: # siehe [Strategie der Punktevergabe](#strategie-der-punktevergabe)
        depends_on: compile
    checkstyle:
        # Individuelle Konfiguration des Tests (Unvollständige Auflistung)
        max_points:    # siehe [Strategie der Punktevergabe](#strategie-der-punktevergabe)
        depends_on:    # Wird nur ausgeführt und gibt nur Punkte, wenn das genannte target bestanden wurde
no_override:           # Liste an Dateien, die nicht mit der Vorlage überschrieben werden dürfen

Strategie der Punktevergabe

Im Gegensatz zum task.json-Vorschlag könnte man die Punktevergabe für jeden Test einzeln lösen, um das Verhältnis auch justieren zu können.

Die Ergebnisse der Toolchain werden in verschiedenen Dateien gespeichert.
Diese müssen im Python Skript eingelesen und ausgewertet werden.
Dafür soll für jeden Task für jedes Kriterium eine "Map" angelegt werden.

• JUnit
  • Wie viele Tests gibt es im LoesungsTestSuit?
  • Wie viele sind gescheitert?
• Spotbugs
  • Wie viele Probleme gibt es pro Stufe?
• Checkstyle
  • Wie viele Probleme gibt es pro Stufe?
• (Spotless)
  • nach absprache mit @AHeinisch

Paper Code Process Metrics in University Programming Education zum Related Work hinzufügen.

Umsetzung des zweiten Schrittes des GH-Action-Ablaufs aus der Dokumentation:

Umsetzung des vierten Schrittes des GH-Action-Ablaufs aus der Dokumentation:

Folgendes sollte aufbereitet in das Related Work unter doc/related_work hinzugefügt werden:

Automatisierte Bewertung in der Programmierausbildung, Oliver J. Bott, Peter Fricke, Uta Priss, Michael Striewe (Hrsg.), 2017, Digitale Medien in der Hochschullehre, Band 6, ISBN 978-3-8309-3606-0

Gibt einen umfangreichen Überblick über das Autograding an deutschen Hochschulen und Universitäten. Es stellt einige aktuell eingesetzte Autograder vor und vergleicht diese.

Für die Einordnung von D2A in das Forschungs-/Entwicklungsgebiet der AutoGrader, siehe #619

Teaching Clean Code, Dietz, Manner, Harrer, Lenhard, 2018, ISEE 2018: 1st Workshop on Innovative Software Engineering Education @ SE18, Ulm, Germany (https://mediatum.ub.tum.de/1428241)

Allgemein: Google Scholar "Teaching Clean Code": https://scholar.google.de/scholar?q=related:Y3CjdfUuTXAJ:scholar.google.com/&scioq=teaching+clean+code&hl=en&as_sdt=0,5

Aus alten Quellenverzeichnis im Dungeon-Repo

Der Link in https://github.com/Programmiermethoden/Deploy-to-Grading/blob/master/doc/related_work/book/bott2017.md zeigt auf das Dietz-Paper und nicht auf das Buch ...

Nach dem gestrigen Meeting habe ich nochmal über die Wahl der richtigen Programmiersprache nachgedacht. Hier mal eine Zusammenfassung dazu:

Frage: Wie relevant ist eigentlich Flexibilität und wie zeichnet die sich aus? Am ehesten wird doch Flexibilität bei der Wahl der Metriken benötigt und da frage ich mich, ob bash oder Java dort einen Unterschied macht. Oder verstehe ich Flexibilität falsch?

Hier mal eine Auflistung, was meiner Einschätzung nach durch welche Sprache am einfachsten umzusetzen wäre:

Bash hat für manche Sachen definitiv Vorteile, da es einfacher ist. Sobald es aber um komplexere Datensätze geht, wäre der Einsatz von Python oder Java wahrscheinlich sinnvoller, wobei ich da eher bei Java bin.

Ich würde mal versuchen, bis nächste Woche Schritt 2 in Bash zu implementieren.

@cagix @AMatutat Was ist eure Ansicht dazu? Falls es etwas länger wird, könnt ihr auch gerne das https://github.com/Programmiermethoden/Deploy-to-Grading/labels/meeting -Label an das Issue packen.

Ziel wäre es, ein Master-Buildskript im vorgabe/.config Verzeichnis.
Diesem Master-Buildskript würde ich folgende Parameter übergeben:

• Welcher Task "gebaut" werden soll
• Wo der zu verwendende loesung Ordner liegt.
• Wo die Ergebnisse von JUnti, Spotbugs und co gespeichert werden sollen
• Wo die Checkstyle config liegt.

Das Master-Buildskript ruft dann das ensprechende Task-Buildskript auf und übergibt die genannten Parameter.
Ausgeführt werden soll:

• build
• test
• spotbugs
• checkstyle
• spotless

Dieses Ticket besteht daher aus zwei Schritten;

• Struktur der Vorgaben (und des Homework-Solution) ändern und für jeden Task ein build.gradle einfügen
• Erstellen des Master-Buildskripts

    vorgabe
        alles_von_gradle
        .config
                python-skript
                master-build.gradle   <- mache $TASK (build.gradle) mit $../../studi-repo/$TASK/loesung und speicher ../../result/$TASK (issue) mit ./checkstyle
                task.jsons
                checkstyle/
                (local.bash (was die action macht))
        task1  
            src/
            test/
                vorgaben/
                loesung/
            build.grade   (<- wo loesung ordner?, wo results speichern?, welcher Checkstyle?)
        task2
            ...
        README.md
        LICENCE.md


    studi-repo
        (alles_von_gradle)
        .config
                (python-skript)
                (master-build.gradle)
                (task.jsons)
                (checkstyle/)
                local.bash (was die action macht)
                
        task1
            (src/)
            (test/)
            loesung/
            (build.gradle)
        task2

    results
        task1
            junit
            spotbugs
            spotless
            checkstyle
            punkte(studi : dieser Task)
            all_outputs.html (spotbugs,junit und co)
        task2
            ...
        gesamtPunkte (studi: gesamtenPunkten)

    


LEGENDE:
    () means: Wird in diesem Repo nicht verwendet

Implementierung der in der Dokumentation beschriebenen Metrik für die Codeformatierung.

Dieses Issue ersetzt #24.

Für eine Publikation sollten wir uns für einen eindeutigen Namen entscheiden. Momentan verwenden wir ja sowohl Deploy-2-Abgabe als auch Deploy-2-Grading.

Basierend auf den Rückmeldungen vom abgelehnten Paper habe ich ein wenig recherchiert und bin auf folgendes gestoßen:
https://www.waxmann.com/automatisiertebewertung/

Was könnte man aus deren Erfahrungen und Umsetzungen für unser D2G nutzen?

@cagix @AMatutat Inwiefern habt ihr euch mit den dort aufgezählten automatischen Bewertungssystemen schon auseinandergesetzt?

Studierende sollen sich die Aufgabenstellungen selbst basierend auf ihrem Vorlesungsfortschritt auswählen und den Abgabetermin selbst terminieren können. Siehe dazu auch folgenden Kommentar:

"Um ein Self-Paced Learning zu ermöglichen, haben wir darauf verzichtet, in die Dungeon-Aufgaben konkrete Bezüge zu den verschiedenen Lehrinhalten zu formulieren: Die Vorlesungsinhalte haben (derzeit noch) einen festen zeitlichen Plan, während die Aufgaben in einer freien zeitlichen Reihenfolge bearbeitet werden können. Anderenfalls könnten bestimmte Aufgaben erst zu einem bestimmten Zeitpunkt bearbeitet werden. Die Studierenden sind aber aufgefordert, die Bezüge zum Vorlesungsstoff selbst herzustellen und beispielsweise ein Pattern zu erkennen und anzuwenden, sofern es bereits in der Vorlesung behandelt wurde. Mit der Einführung eines automatisierten Bewertungssystems soll es auch wieder Aufgaben geben, die sich spezifisch mit bestimmten Vorlesungsthemen auseinander setzen bzw. die Vorlesungsthemen spezifisch in die Dungeon-Aufgaben integrieren. Zusätzlich sollen dann auch die Vorlesungsthemen in einer relativ freien zeitlichen Reihenfolge bearbeitet werden können - das automatisierte Bewertungssystem ermöglicht diesen Spielraum."

Originally posted by @cagix in https://github.com/Programmiermethoden/2022-freiraum-dungeon/pull/146#discussion_r1219166273

Eine Auflistung an möglichen Metriken, mit denen die Abgaben bewertet werden sollen. Die Metriken sind unterteilt in Metriken, die von Studierenden selbst ausgeführt werden können (durch die GH-Action) und Metriken, die nur bei der endgültigen Bewertung eingesetzt werden können, da sie z.B. Gruppenübergreifend arbeiten.

Für alle (insbesondere Studierende)

Nur für die endgültige Bewertung

Da IDEs aus jeden Subprojekt ein Modul machen muss einmal kontrolliert werden, ob die .editorconfig vom rootprojekt greift oder ob jedes Subprojekt diese Datei benötigt.

Implementierung der in der Dokumentation beschriebenen Metrik für das Kompilieren.

Basierend auf folgendem Kommentar könnten wir eine GUI zum Erstellen der yaml-Dateien basteln. Webbasiert, da das wahrscheinlich der einfachste Weg ist, die an Studis zu verteilen. Könnte man z.B. über das ILIAS HTML Lernmodul hosten?

"Im Prinzip müsste man wochenweise Deadlines als solche vorgeben und die Studis können sich nach irgendwelchen Regeln für jede Deadline Aufgaben zusammensuchen. D.h. sie müssten sich tatsächlich eine Art Konfiguration zusammen bauen (lassen) - vielleicht könnten wir dann eine Art GUI anbieten, wo man die Deadlines und Aufgaben auswählen (anklicken) kann, und wo dann das passende .yaml rausfällt? Die GUI selbst sollte auf einer .yaml von uns basieren, d.h. mit den Deadlines und Aufgaben und so und daraus dynamisch eine Ansicht generieren."

Originally posted by @cagix in https://github.com/Programmiermethoden/2022-freiraum-dungeon/pull/146#discussion_r1221263741

Edit: Die Frage ist, ob das webbasiert sein muss - das zieht gleich wieder Fragen nach einem Server o.ä. nach sich. Mir würde eine einfache Swing-basierte Lösung völlig reichen, die man per .jar verteilt und die die Studis direkt starten können.

Implementierung der in der Dokumentation beschriebenen Metrik für JavaDoc Dokumentation.

Umsetzung der Schritte 1, 2 und 4 für die Ausführung durch Lehrende.