Ce se întâmplă după ce GitLab primește codul?

GitLab, atunci când primește un cod (de obicei prin git push), inițiază un proces care depinde de setările proiectului:

1. Webhooks: Când ajunge un cod nou, GitLab poate notifica sisteme externe (de exemplu, servere CI/CD, sisteme de gestionare a proiectelor) trimițând solicitări HTTP. Acest lucru servește ca un declanșator pentru acțiuni ulterioare.

2. Pipeline CI/CD: Dacă fișierul .gitlab-ci.yml este configurat în proiect, GitLab Runner pornește pipeline-ul CI/CD. Acest proces include:

   • Verificarea sintaxei fișierului .gitlab-ci.yml.
   • Crearea de sarcini (jobs) bazate pe definițiile din fișierul yml.
   • Atribuirea sarcinilor la runner-ii disponibili.
   • Runner-ul primește sarcinile, descarcă codul sursă al depozitului.
   • Execută comenzile specificate pentru fiecare sarcină (build, testare, implementare etc.).
   • Salvează artefacte (aplicații compilate, rapoarte de testare) și fișiere de jurnal.
   • Trimite statusul sarcinilor înapoi la GitLab.

   Exemplu de structură .gitlab-ci.yml:

   stages:
     - build
     - test
     - deploy
   
   build_job:
     stage: build
     script:
       - echo "Construind aplicația..."
       - make build
   
   test_job:
     stage: test
     script:
       - echo "Rulând testele..."
       - make test
   
   deploy_job:
     stage: deploy
     script:
       - echo "Implementând aplicația..."
       - make deploy
     only:
       - main  # Trigger doar la push pe branch-ul main
   

3. Acțiuni automate: GitLab poate efectua alte acțiuni automate:

   • Crearea unui Merge Request (la push pe un branch diferit de cel țintă).
   • Actualizarea stării Merge Request-ului (dacă există).
   • Rularea scanărilor de securitate (dacă sunt configurate).
   • Închiderea automată sau legarea de sarcini (prin cuvinte cheie în commit-uri sau în descrierea Merge Request-ului).

4. Sistem de notificări: GitLab trimite notificări utilizatorilor prin e-mail sau alte canale (Slack, Mattermost), dacă aceștia sunt abonați la evenimentele din depozit (noi commit-uri, starea pipeline-ului, comentarii).

5. Actualizarea datelor depozitului: În mod intern, GitLab actualizează datele despre depozit, ramuri, etichete și istoricul commit-urilor.

Procesul în general are ca scop integrarea noului cod în fluxul de lucru general, automatizarea construirii, testării și, eventual, implementării, precum și notificarea părților interesate.