Changes for page GitLab Erklärungen

Last modified by pmeyer on 2025/09/12 04:41

edited by sbeyer1
on 2025/08/25 11:50
Change comment: There is no comment for this version
edited by sbeyer1
on 2025/08/25 23:17
Change comment: Uploaded new attachment "1756156620220-340.png", version {1}

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -175,6 +175,8 @@
175 175  (% class="wikigeneratedid" id="H" %)
176 176  [[image:Wiki5.png||data-xwiki-image-style-border="true"]]
177 177  
178 +----
179 +
178 178  = Zeiterfassung in GitLab =
179 179  
180 180  Im Rahmen des Softwareprojekts sollt ihr eure Arbeitszeit präzise festhalten. Dazu könnt ihr direkt auf angelegten Issues/Tasks/User Stories in dem Bereich **Time tracking** eure Arbeitszeit Aufgabenspezifisch eintragen. In dem Fenster könnt ihr eintragen wie viel Zeit ihr gearbeitet habt, an welchem Tag ihr gearbeitet habt, um nachträgliches verbuchen von Arbeitszeit zu ermöglichen, und eine kleine Zusammenfassung angeben. Sollte bereits Zeit erfasst worden sein, muss über das Plus (siehe Bild oben rechts im roten Rahmen) Zeit gebucht werden.[[image:1754139824426-497.png]]
... ... @@ -200,7 +200,7 @@
200 200  
201 201  Der //verify-job //ist der erste Job, der in der Pipeline definiert ist. Er wird in der //verify-//Stage ausgeführt. Das Image ist ein Docker-Image, welches schon mit einer Java 21 Umgebung eingerichtet ist. Dadurch wird sichergestellt, dass der Job immer die gleiche Umgebung hat ("//but it works on my machine"//).
202 202  Im Script-Abschnitt wird dann mvn clean verify ausgeführt. Maven verify baut das Projekt und führt die Tests im Projekt aus.
203 -Die Rules definieren, wann ein Job ausgeführt wird und ob das Fehlschlagen des Jobs erlaubt ist. Regeln werden von oben nach unten ausgewertet. //$CI_PIPELINE_SOURCE == "schedule" //sagt dass der Job bei automatischen Aufrufen über einen zeitgesteuerten Start der Pipeline mit besonderen Einschränkungen ausgeführt werden soll. //allow_failure//
205 +Die Rules definieren, wann ein Job ausgeführt wird und ob das Fehlschlagen des Jobs erlaubt ist. Regeln werden von oben nach unten ausgewertet. //$CI_PIPELINE_SOURCE == "schedule" //sagt dass der Job bei automatischen Aufrufen über einen zeitgesteuerten Start der Pipeline mit besonderen Einschränkungen ausgeführt werden soll. //allow_failure// erlaubt in dem Fall, dass bei automatischer Ausführung die Pipeline nicht abgebrochen wird, falls sich euer Projekt nicht bauen lässt, damit darauffolgende Jobs weiterhin ausgeführt werden.
204 204  
205 205  {{code language="yaml"}}
206 206  verify-job:
... ... @@ -215,3 +215,51 @@
215 215   - when: always
216 216   allow_failure: false
217 217  {{/code}}
220 +
221 +(((
222 + Der //deploy_stats_pages// Job ist der erste Job, der in der //deploy//-Stage ausgeführt wird. Der Job erfasst eure Projektarbeitsdaten (bspw. eure Stundenbuchungen) und veröffentlicht diese, nur für euch in GitLab sichtbar, in eurem Projekt.
223 +Die Variablen sind Umgebungsvariablen, die zum Erfassen der Daten benötigt werden. **Die //TIME_FRAMES// Variable ist auskommentiert und sollte durch euren projektverantwortlichen Betreuer:in (Tutor:in) angepasst werden.** Durch die //TIME_FRAMES// Variable können die [[Einschätzungszeiträume>>https://xwiki.swl.informatik.uni-oldenburg.de/xwiki/bin/view/Main/Bewertung/#HBewertungszeitrE4ume]] sowie die "Soll-Zeit" pro Zeitraum gesetzt und für die Visualisierung verwendet werden.
224 +Im Script-Bereich wird erst git installiert und dann die Projekete zur Erfassung und Visualisierung der Daten installiert.
225 +Der Artifakt-Bereich definiert welche Dateien nach Ausführung des Jobs behalten werden. Der Public Ordner wird verwendet, um statische Websiten zu veröffentlichen. In diesem Fall die Visualisierung der erfassten Daten.
226 +Im Gegensatz zum //verify-job// wird der //deploy_stats_pages//-Job **nur** ausgeführt, wenn die Pipeline zeitgesteuert gestartet wird.
227 +
228 +{{code language="yaml"}}
229 +deploy_stats_pages:
230 + stage: deploy
231 + image: maven:3.9.9-amazoncorretto-21-al2023
232 + variables:
233 + DEVELOPMENT_BRANCH_NAME: "development"
234 + FETCH_MULTITHREAD: "true" #options are true/false
235 + LOGLEVEL: "SHORT" #options are OFF, SHORT, LONG. Has an effect on the amount of logging when data is being added
236 + #TIME_FRAMES: "01.01.2025,31.03.2025,40,Zeitraum01;01.04.2025,31.05.2025,35" #Format start,end,minHours[,name];anotherTimeframe;anotherTimeframe;...
237 + script:
238 + - yum install -y git rsync
239 + - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/gitlab2data.git
240 + - cd gitlab2data
241 + - mvn clean package
242 + - java -jar target/GitLab2Data-1.0-SNAPSHOT-jar-with-dependencies.jar
243 + - cd ..
244 + - mkdir -p public/data
245 + - rm -f public/data/*.json
246 + - cp gitlab2data/*.json public/data/
247 + - git clone https://gitlab.swl.informatik.uni-oldenburg.de/GA/data4visual.git repo
248 + - rsync -av --exclude='data/' --exclude='.git' --exclude='.gitignore' repo/ public/
249 + artifacts:
250 + paths:
251 + - public
252 + pages:
253 + path_prefix: "stats" #to allow for parallel deployments of the projects own page don't make the stats site the main deployment
254 + expire_in: never
255 + rules:
256 + - if: $CI_PIPELINE_SOURCE == "schedule"
257 + when: always
258 + - when: never
259 +{{/code}}
260 +
261 +----
262 +
263 += GitLab Pages (Einsehen der erfassten Projektdaten) =
264 +)))
265 +
266 + Wie im vorherigen Abschnitt beschrieben, werden im Softwareprojekt mit Hilfe der Pipeline Daten erfasst. Diese Daten können dann aus GitLab eingesehen werden, dazu 
267 +[[image:1756156505473-305.png||alt="Pages können im Projekt über Deploy -> Pages eingesehen werden"]]
attach_file 1756156505473-305.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +148.9 KB
Content info
attach_file 1756156620220-340.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.sbeyer1
Size
... ... @@ -1,0 +1,1 @@
1 +30.7 KB
Content info