Um auf Ihr htwg-syslab-bsys beheimatete Repository für das BSYS Labor zu erhalten, müssen Sie einige Punkte vorab durchführen:
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.
grp0. Achten Sie genau auf die Schreibweise (Gross/Klein-Schreibung)Um Ihr git Repository von github bequem auschecken zu können, muss zuvor ein SSH-Key generiert werden. Dieser ssh Key muss PRO Rechner erstellt werden, von welchem Sie auf das Repository zugreifen wollen. Wenn Sie z.B. von einem Notebook und Ihrer zugewiesenen Workstation arbeiten wollen, so müssen Sie für beide Rechner jeweils den ssh Key erstellen und auf github in Ihren Settings den ‘public’ Teil des jeweiligen Keys hinzufügen.
Wenn Sie noch keinen ssh Key erstellt haben so ist in auf Github beschrieben, wie das aus einem Linux System funktioniert. Den Teil mit dem ssh-agent können Sie überspringen. Der erzeugte Public Key muss dann noch zu github kopiert werden. Danach kann über eine sichere ssh Verbindung der Transfer zwischen Github und dem Rechner stattfinden. Da dieser Transfer für jede Rechnerverbindung benötigt wird, müssen Sie auf jedem verwendeten Rechner einen Schlüssel erstellen.
Nachdem Sie erfolgreich eine lokale Arbeitsversion Ihres geforkten Gruppenrepositories (Developer-Repo) erstellt haben, können Sie den Inhalt editieren.
In diesem Ihrem Repository werden Sie Ihre Lösungen zu den Homeworks aus dem BSYS Labor sammeln. Dazu wird im weiteren exemplarisch von obiger Gruppe: ‘Susi Sorglos’ und ‘Willi Wacker’ ausgegangen.
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.
Die Lösungen müssen in einer bestimmten Ordnerstruktur liegen, die wie folgt aussieht:
...
hw1/
README.md
task1/
task2/
simu1/
hw2/
README.md
task1/
task2/
simu1/
...
In den taskN-Unterordnern muss Ihre Lösung für die entsprechende Programmieraufgabe
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.
Neue Übungsaufgaben werden in einem separaten Homework Repository veröffentlicht. Es kann vorkommen, dass mit der Aufgabenstellung schon ein paar Quelldateien vorgegeben werden; diese müssen Sie dann von dem genannten Repository in Ihren Fork kopieren. Beachten Sie bitte, dass die Ordnerstruktur genau den Vorgaben entsprechen muss.
Auch wird für jede Homework eine Datei unter files/ bereit gestellt. Diese wird bei den Tests benutzt, um zu überprüfen, ob Sie alle geforderten Dateien erstellt haben und hilft Ihnen bei der Überprüfung der Vollständigkeit Ihrer Lösung.
Dies geht am besten, indem Sie beide Repositories (Ihren Fork des
Gruppenrepositories und das Aufgaben Repository) in den selben Ordner klonen (sodass sie nebeneinander liegen). Das ganze sieht dann in etwa im Ordner von Susi Sorglos (aus grp0) so aus:
$ git clone git@github.com:SusiSorglos/bsys-ws17-grp0.git
$ git clone https://github.com/htwg-syslab-bsys/bsys-ws17-homework.git
$ ls
bsys-ws17-grp0/ bsys-ws17-homework/
Wenn eine neue Aufgabe veröffentlicht wurde, muss zunächst
bsys-ws17-homework aktualisiert werden:
$ cd bsys-ws17-homework
$ git pull
$ cd ..
Nun kann die Aufgabenstellung (mit Quelldateien) der Nten Homework
in Ihren Fork kopiert werden:
$ cp -r bsys-ws17-homework/hwN bsys-ws17-grp0/
Um das Arbeiten zu erleichtern, ist für alle Lösungsrepositories ein Continuous 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.
Jeder PR hat also einen Status: passed, failed oder pending. Ihre PR zum Einreichen (Deadline) der Aufgaben muss den Status passed erreicht haben, also planen Sie genug Zeit zum Verbessern von kleinen Fehlern ein und öffnen den PR nicht erst kurz vor Schluss.
./ci/run-all.sh
ci/run-all.sh, daher MÜSSEN Sie unbedingt selbst im lokalen Verzeichnis auf Ihrer Workstation den ci/run-all.sh Test ausführen!files\ Datei in Ihr Repository kopiert haben, so wird beim Durchlaufen aller Tests auch die Existenz der geforderten Dateien in Ihrer Lösung überprüftAchtung: 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.
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.