|
|
@@ -1,3 +1,13 @@
|
|
|
1
|
+- [Vorbereitung](#vorbereitung)
|
|
|
2
|
+ - [User A and User B @ Github:](#user-a-and-user-b-github)
|
|
|
3
|
+- [Git and GitHub Preparations](#git-and-github-preparations)
|
|
|
4
|
+ - [User A @ GitHub](#user-a-github)
|
|
|
5
|
+ - [User A @ Container:](#user-a-container)
|
|
|
6
|
+ - [User B @ Container:](#user-b-container)
|
|
|
7
|
+- [Schritte zum Pull-Request](#schritte-zum-pull-request)
|
|
|
8
|
+- [Travis-CI](#travis-ci)
|
|
|
9
|
+- [gitignore](#gitignore)
|
|
|
10
|
+
|
|
1
|
11
|
# Laborzugang einrichten
|
|
2
|
12
|
|
|
3
|
13
|
1. Beachten Sie die Ankündigungen im Moodle Forum. Dort werden die Termine zur Anmeldung als 2er Gruppe sowie die Freischaltung Ihrer Workstation bekannt gegeben. Beachten Sie bitte unbedingt die Deadlines dazu!
|
|
|
@@ -54,5 +64,59 @@ git remote add upstream git@github.com:htwg-syslab-bsys-ws17/bsys-ws17-grpN.git
|
|
54
|
64
|
|
|
55
|
65
|
Selbes Vorgehen wie User A im vorherigen Abschnitt
|
|
56
|
66
|
|
|
|
67
|
+# Abgabe der Homeworks
|
|
|
68
|
+
|
|
|
69
|
+Sobald Sie alle Aufgaben eines Aufgabenblattes (homework) bearbeitet haben, erstellen Sie einen sogenannten *Pull Request* (PR) von Ihrem Branch, den Sie zum Review abgeben wollen.
|
|
|
70
|
+
|
|
|
71
|
+Die Lösungen müssen in einer bestimmten Ordnerstruktur liegen, die wie folgt
|
|
|
72
|
+aussieht:
|
|
|
73
|
+
|
|
|
74
|
+```
|
|
|
75
|
+...
|
|
|
76
|
+hw1/
|
|
|
77
|
+ README.md
|
|
|
78
|
+ task1/
|
|
|
79
|
+ task2/
|
|
|
80
|
+ simu1/
|
|
|
81
|
+hw2/
|
|
|
82
|
+ README.md
|
|
|
83
|
+ task1/
|
|
|
84
|
+ task2/
|
|
|
85
|
+ simu1/
|
|
|
86
|
+...
|
|
|
87
|
+```
|
|
|
88
|
+
|
|
|
89
|
+In den `taskN`-Unterordnern muss Ihre Lösung für die entsprechende Programmieraufgabe
|
|
|
90
|
+liegen. in den `simuN`-Unterordnern liegen Ihre Antworten zu den Simulationsaufgaben. Im jeweiligen **README.md** der Homeworks (`hwN`) finden Sie dazu die nötigen Informationen und Aufgaben.
|
|
|
91
|
+
|
|
|
92
|
+## Schritte zum Pull-Request
|
|
|
93
|
+1. Überprüfen Sie den Inhalt Ihres Repository. Achten Sie darauf, dass alle Dateien und die jeweiligen Versionen der Dateien die Sie abgeben wollen nicht nur lokal in Ihrem Home Verzeichnis liegen sondern auch in Ihrem Repository auf github.
|
|
|
94
|
+1. Überprüfen Sie die Ausgabe Ihrer Programme. Stimmen die Ausgaben mit den geforderten Ausgaben überein?
|
|
|
95
|
+1. Lassen Sie alle Tests laufen indem Sie im Wurzelverzeichnes des Repositories folgenden Befehl ausführen (nur Linux und Verwandte!):
|
|
|
96
|
+
|
|
|
97
|
+```
|
|
|
98
|
+./ci/run-all.sh
|
|
|
99
|
+```
|
|
|
100
|
+
|
|
|
101
|
+1. Sobald Sie alle Aufgaben bearbeitet haben, und zur Bewertung die Aufgabe abgeben wollen, erstellen Sie einen Branch für den Pull-Request.
|
|
|
102
|
+1. Wählen Sie dann auf github diesen Branch aus und öffnen Sie einen Pull-Reqeust auf diesen Branch. Vergessen Sie nicht einen Tutor als Reviewer einzutragen.
|
|
|
103
|
+1. Bei Ihrem Pull-Request laufen automatische Tests durch, die Ihr Programm testen. Dies sind nicht alle Tests von `ci/run-all.sh`, daher MÜSSEN Sie unbedingt selbst im lokalen Verzeichnis auf Ihrer Workstation den `ci/run-all.sh` Test ausführen!
|
|
|
104
|
+1. Falls Ihnen ein Fehler unterlaufen ist, so können Sie auch nach dem Pull-Request noch Änderungen am Code vornehmen. Das sollte jedoch der Ausnahmefall bleiben. Überprüfen Sie daher VOR Ihrem Pull-Request, ob die nötigen Aufgaben bearbeitet wurden und ob die Tests alle durchlaufen.
|
|
|
105
|
+
|
|
|
106
|
+
|
|
|
107
|
+## Travis-CI
|
|
|
108
|
+
|
|
|
109
|
+Um das Arbeiten zu erleichtern, ist für alle Lösungsrepositories ein Continuous
|
|
|
110
|
+Integration Service aufgesetzt worden. Jedes mal, wenn ein Pull Request (PR) geöffnet oder aktualisiert wird, laufen eine Reihe von Tests für Ihre Programmieraufgaben durch, die den Codestil prüfen, alle Rust Dateien kompilieren und alle Unit-Tests ausführen.
|
|
|
111
|
+
|
|
|
112
|
+Jeder PR hat also einen Status: *passed*, *failed* oder *pending*. Ihre PR zum
|
|
|
113
|
+Einreichen (Deadline) der Aufgaben muss den Status *passed* erreicht
|
|
|
114
|
+haben, also planen Sie genug Zeit zum Verbessern von kleinen Fehlern ein und öffnen den PR nicht erst kurz vor Schluss.
|
|
|
115
|
+
|
|
|
116
|
+>Achtung: Damit das Testen in github nicht zu lange dauert, sind einige sehr lang laufende CI Tests deaktiviert. Bitte aktivieren Sie diese Tests NICHT für travis sondern führen Sie die Tests nur lokal aus. Github Classroom erlaubt nur immer eine laufende Instanz der Travis Tests. Erstellen Sie somit Ihren Pull-Request rechtzeitig, da ansonsten die Deadline aufgrund anderer laufender CI Tests von Ihnen u.U. nicht eingehalten werden kann.
|
|
|
117
|
+
|
|
|
118
|
+## gitignore
|
|
|
119
|
+
|
|
|
120
|
+Ebenfalls in Ihrem Repository ist bereits eine `.gitignore` Datei im Root Ordner. Damit werden von git gewisse Dateitypen und Directories in Ihren `hwN/` Verzeichnisse ignoriert, so dass Sie diese nicht Ihrem Repository hinzufügen. Achten Sie dennoch drauf, welche Dateien Sie in Ihr Repository hinzufügen, denn in `.gitignore` sind nicht alle Möglichkeiten abgefangen. Fügen Sie mit **git add** immer nur selektiv Dateien hinzu.
|
|
57
|
121
|
|
|
58
|
122
|
[SYSLAB]: https://htwg-syslab.github.io
|