Ce se întâmplă după ce GitLab descarcă codul?

După ce GitLab descarcă codul depozitului în directorul de lucru, începe executarea pipeline-ului CI/CD definit în fișierul .gitlab-ci.yml.

1. Analiza fișierului .gitlab-ci.yml: GitLab Runner (sau GitLab însuși, dacă se folosește CI încorporat) citește configurația din .gitlab-ci.yml. Acest fișier descrie etapele (stages) și sarcinile (jobs) pipeline-ului.
2. Inițializarea Runner-ului: Se alocă un GitLab Runner disponibil pentru a executa pipeline-ul. Runner-ul obține informații despre depozit, commit, branch și configurația din .gitlab-ci.yml.
3. Crearea mediului de execuție: Runner-ul pregătește un mediu pentru executarea sarcinilor. Acesta poate fi:
   • Mașină virtuală
   • Container (Docker, Kubernetes)
   • Server dedicat
   • Shell
4. Executarea etapelor (stages): Pipeline-ul se execută secvențial pe etape, definite în .gitlab-ci.yml. Sarcinile din aceeași etapă pot fi executate în paralel.
5. Executarea sarcinilor (jobs): În interiorul fiecărei etape, se execută sarcinile configurate. O sarcină include:
   • Definirea imaginii sau executorului (executor), dacă nu este specificat la nivel de pipeline sau secțiune variables.
   • Clonarea depozitului (deja realizată de GitLab, dar Runner-ul poate executa git fetch sau git checkout pentru starea necesară).
   • Restaurarea cache-ului (dacă este configurat) pentru accelerarea compilării (de exemplu, încărcarea dependențelor).
   • Executarea scripturilor (script): Aceasta este conținutul principal al sarcinii, unde se execută comenzi de build, testare, analiză sau deploy.
   • Încărcarea artefactelor (dacă este configurat): Rezultatele sarcinii (de exemplu, binare compilate, rapoarte) sunt salvate pentru utilizare sau descărcare ulterioară.
   • Salvarea cache-ului (dacă este configurat) pentru a accelera execuțiile viitoare.
6. Raportarea statusului: Runner-ul trimite statusul fiecărei sarcini (succes, eroare, anulare) înapoi către GitLab. Utilizatorul vede progresul și rezultatele pe pagina pipeline-ului.
7. Trecerea la următoarea etapă: Dacă toate sarcinile din etapa curentă s-au finalizat cu succes (sau dacă allow_failure este setat), începe următoarea etapă. Dacă o sarcină se încheie cu eroare și allow_failure nu este setat, întregul pipeline se întrerupe.
8. Finalizarea pipeline-ului: După executarea tuturor etapelor (sau în caz de eroare), pipeline-ul se încheie. Rezultatele și artefactele sunt disponibile prin interfața web GitLab.

Exemplu de structură a fișierului .gitlab-ci.yml:

// Definirea etapelor pipeline-ului
stages:
  - build
  - test
  - deploy

// Sarcina de build în etapa build
build_job:
  stage: build
  image: docker:latest // Folosim o imagine Docker
  script:
    - echo "Construiesc aplicația..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Construirea imaginii Docker
  artifacts:
    paths:
      - myapp.tar // Salvarea artefactului de build

// Sarcina de test în etapa test
test_job:
  stage: test
  image: python:3.9 // Folosim o imagine Python
  script:
    - echo "Execut testele..."
    - pip install -r requirements.txt
    - pytest // Executarea testelor
  needs: ["build_job"] // Depinde de finalizarea cu succes a build_job

// Sarcina de deploy în etapa deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // Folosim o imagine Ubuntu
  script:
    - echo "Deploy aplicația..."
    - echo "Aici va fi scriptul de deploy..." // Script de deploy
  only: // Se rulează doar pentru commit-uri pe master sau etichete
    - master
    - tags
  needs: ["test_job"] // Depinde de finalizarea cu succes a test_job

Astfel, descărcarea codului este doar primul pas, urmat de un proces complex de build, testare și deploy automatizat, bazat pe configurația .gitlab-ci.yml.