Selaa lähdekoodia

Merge pull request #13 from htwg-syslab-bsys-ws17/mm_merge_content

README now contains all relevant BSYS info
Michael Mächtel 8 vuotta sitten
vanhempi
commit
c2ab6ef25c
2 muutettua tiedostoa jossa 65 lisäystä ja 23 poistoa
  1. 0
    22
      OVERVIEW.md
  2. 65
    1
      README.md

+ 0
- 22
OVERVIEW.md Näytä tiedosto

@@ -1,22 +0,0 @@
1
-# Übersicht zum Ablauf der Übungsaufgaben im HTWG Modul BSYS
2
-
3
-## Vorbereitung
4
-
5
-
6
-
7
-### Fork des htwg-syslab-bsys GitHub Repository
8
-
9
-Um auf Ihr htwg-syslab-bsys beheimatete Repository für das BSYS Labor zu erhalten, müssen Sie einige Punkte vorab durchführen:
10
-
11
-1. Legen Sie sich - soweit noch nicht vorhanden - einen GitHub Account an.
12
-1. Über den Einladungslink im Moodle-Forum erstellen Sie Ihre Labor-Gruppe unter htwg-syslab-bsys auf github.
13
-
14
->Es macht keinen Sinn eine 1er Gruppe anzumelden, wenn Sie noch keinen Partner gefunden haben, da Sie immer beide RZ-IDs zum Anmelden benötigen. Bitte suchen Sie sich zeitnah einen Partner, mit dem Sie das Labor bestreiten wollen.
15
-
16
-1. ***WICHTIG***: Sie legen sich nun eine Gruppe für Ihr 2er Team an.
17
-    - Name der Gruppe: Benutzen die als Namen den String Ihre Gruppe aus Moodle, also z.B. `grp0`. Achten Sie genau auf die Schreibweise (Gross/Klein-Schreibung)
18
-    - Der 2. Teilnehmer meldet sich zu dieser neuen Gruppe an.
19
-1. Sie landen auf der "Ready to go" Seite. Dort nehmen Sie bitte zuerst die Einladung an, indem Sie auf den *@htwg-syslab-bsys* Link klicken. Nach der Annahme der Einladung können Sie auf Ihr 'Assignment'-Repository per Browser zugreifen
20
-1. ***WICHTIG***: Einer(!) in Ihrem 2er Team forkt nun das Projekt, so dass der Fork Ihres Projektes in IHREM Github Account liegt. Mit diesem geforkten Repository werden Sie zunächst arbeiten. Damit der Partner in Ihrem Team auch mit diesem Repository arbeiten kann, müssen Sie ihn in den Einstellungen zu Ihrem Projekt auf github dazu autorisieren.
21
-    - Führen Sie keine Änderungen auf dem Repository im htwg-syslab-bsys Bereich durch, sondern NUR im geforkten Rep in Ihrem privaten github Account.
22
-

+ 65
- 1
README.md Näytä tiedosto

@@ -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!
@@ -8,7 +18,7 @@
8 18
 
9 19
 # Aufgaben zum BSYS Labor
10 20
 
11
-In diesem Ordner werden die Aufgaben (Homework,`hw`) veröffentlicht, die bearbeitet werden müssen, um den Schein in BSYS zu bekommen. In der Datei `OVERVIEW.md` in diesem Ordner sind weitere Informationen enthalten.
21
+In diesem Ordner werden die Aufgaben (Homework,`hw`) veröffentlicht, die bearbeitet werden müssen, um den Schein in BSYS zu bekommen.
12 22
 
13 23
 Eine Homework besteht aus einer oder mehreren Tasks. Sie finden somit die zu einer Homework gehörenden Aufgaben in den `README.md`, Dateien der zughörigen `hwN/taskN/` Ordner. `N` steht als Platzhalter für die entsprechende Homework bzw. Tasknummer.
14 24
 
@@ -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 Tasks einer Homework bearbeitet haben, erstellen Sie einen sogenannten  *Pull Request* (PR) von Ihrem Branch, den Sie zum Review abgeben wollen. Der Ablauf wird hier erklärt, gleich zu Anfang in der hw0 geübt und sollte spätestens dabei klar werden.
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 erstellen Sie einen Pull-Reqeust auf diesen Branch.
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) erstellt 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 erstellen den PR nicht erst kurz vor der Deadline. Zur Verbesserung fügen Sie einfach weitere Commits zu der Branch hinzu von der aus der Pull-Request erstellt wurde. Dieser wird auf GitHub dann automatisch aktualisiert.
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

Loading…
Peruuta
Tallenna