Preskočiť na obsah

3. Overenie možností získavania údajov

Návrh nástroja závisí od toho, či sa požiadavky predmetu dajú previesť na údaje, ktoré GitLab skutočne poskytuje. Webhook oznamuje zmenu, ale nemusí obsahovať všetky údaje potrebné na vyhodnotenie. REST API poskytuje podrobný aktuálny stav, no jeho pravidelné prehľadávanie pre všetky projekty by bolo pomalé a zbytočne by zaťažovalo GitLab.

3.1 Metóda overenia

Overenie malo tri kroky:

  1. R01-R13 boli rozložené na najmenšie údaje potrebné na rozhodnutie.
  2. Údaje boli porovnané s oficiálnou dokumentáciou webhookov a REST API GitLab.
  3. Mapovanie bolo porovnané s implementáciou a overené automatickými testami.

Kontrolované boli udalosti Push, Issue, Merge Request, Note, Pipeline, Tag Push a zmeny členstva. Pri každej položke sa rozlišovalo, či telo udalosti postačuje, či je udalosť iba spúšťačom doplnenia alebo či treba úplnú synchronizáciu.

Vybraný súbor 350 testov bol spustený 19. júna 2026 v prostredí Python 3.12. Všetky testy prešli. Výsledok dokladá správanie implementácie pri pripravených vstupoch, nie pedagogický prínos ani správnosť pri každom reálnom projekte. Syntetické vstupy testov sa nevydávajú za pozorovanie skutočného kurzu.

3.2 Webhook ako oznámenie zmeny

GitLab môže jednu udalosť doručiť opakovane. Prototyp preto ukladá identifikátor X-Gitlab-Event-UUID; pri chýbajúcej hlavičke vytvorí deterministický odtlačok z obsahu. Jedinečný kľúč v databáze zabráni dvojitému započítaniu.

Webhook nie je úplnou kópiou objektu GitLab. Udalosť Merge Request oznamuje zmenu žiadosti, ale zoznam zmien, diskusií a schválení sa doplní cez REST API. Udalosť Note prináša nový komentár, nie celé diskusné vlákno. Pipeline oznamuje stav procesu, ale R12 potrebuje aj zoznam jeho úloh. Push môže obsahovať iba obmedzený zoznam odovzdaní.

Použitý model je preto "udalosť ako signál, REST API ako zdroj detailu". Webhook spustí krátke prijatie a náročnejšie doplnenie pokračuje vo fronte. Ručná synchronizácia slúži na prvotné naplnenie, opravu alebo vedomú obnovu. Prototyp v pevných intervaloch nesťahuje celý GitLab.

3.3 Mapovanie kontrol na zdroje údajov

ID Spúšťač Doplnenie cez REST Hranica interpretácie
R01 Issue problém a priradenie Priradenie nepreukazuje vykonanú prácu.
R02 Merge Request zdrojová vetva Konvencia názvu je voliteľná podľa kurzu.
R03 Merge Request zmenené súbory Názov súboru nepreukazuje kvalitu testu.
R04 Merge Request opis a väzba na problém Odkaz nepreukazuje vecnú zhodu.
R05 Merge Request úplný opis Dĺžka a šablóna sú iba formálne minimum.
R06 Note poznámky a diskusie Dĺžka komentára je iba zástupný ukazovateľ.
R07 Note poznámky naprieč žiadosťami Počet nevyjadruje náročnosť revízie.
R08 Note vlákna a odpovede autora Samostatné komentáre sa párujú iba približne.
R09 Merge Request schválenia Schválenie nepreukazuje priebeh kontroly.
R10 Merge Request údaj merged_by Povolená osoba závisí od kurzu.
R11 Issue + Merge Request stav prepojených objektov Bez väzby je výsledok menej istý.
R12 Pipeline proces a jeho úlohy Úspech platí iba pre spustené úlohy.
R13 Push + synchronizácia história odovzdaní Vzor správy nepreukazuje použitý editor.

R03-R05 kontrolujú formálne stopy v žiadosti, nie správnosť implementácie. R06-R09 sledujú účasť na revízii, ale neposudzujú technickú pravdivosť komentára. R13 pracuje s neistým zástupným ukazovateľom a má predvolene nulovú váhu.

3.4 Zistenia pre návrh prototypu

Všetkých trinásť kontrol má dostupný technický vstup, no ich výpovedná hodnota sa líši. Každý výsledok preto musí obsahovať pôvod a vysvetlenie, aby ho bolo možné porovnať s GitLabom. Webhooky poskytujú rýchly signál, REST API úplnejší stav a ručná synchronizácia opravný mechanizmus.

Technická kontrola môže upozorniť na chýbajúci artefakt, ale nemá rozhodovať o etickom správaní ani o známke. Pôvodne uvažovaná detekcia "hraného" plnenia bola odstránená, pretože miešala neúplné signály s pedagogickým záverom. Prototyp používa transparentné R01-R13 a ručné overenie sporných prípadov.

Zdroje rozhraní