https://www.youtube.com/watch?v=PGyhBwLyK2U
Per setuppare una pipeline su gitlab basta creare il file .gitlab-ci.yml nella root della repository.
Possiamo definire il nome di un job, e i relativi script da cui esso è composto, e specificare immagini docker da usare.
Ad esempio,
build laptop:
image: alpine
script:
- echo "Building a laptop"
- mkdir build
- touch build/computer.txt
- echo "Mainboard" >> build/computer.txt
- cat build/computer.txt
NB: la repository non conterrà nessun file creato durante l’esecuzione dei job.
Di default vengono utilizzati degli shared runners, ma possiamo configurare runner specifici anche su server di nostra proprietà (anche il nostro pc volendo).
Possiamo specificare diversi stages, in modo che i jobs vengano eseguiti con un ordine sensato:
stages:
- build
- test
nomejob:
stage: build
...
nomejob2:
stage: test
...
NB: se non specifichiamo nessuno stage nella definizione di un job, verrà usato lo stage test come default
Normalmente, l’immagine docker creata per uno stage viene eliminata quando questo ha terminato, quindi job futuri non potranno vedere file o cartelle create da job precedenti. Se questo dovesse essere necessario è possibile specificare i percorsi da mantenere tramite la definizione di artifacts (che verranno salvati dal GitLab server, non dai runner):
build laptop:
image: alpine
stage: build
script:
- echo "Building a laptop"
- mkdir build
- touch build/computer.txt
- echo "Mainboard" >> build/computer.txt
- cat build/computer.txt
artifacts:
paths:
- build
test laptop:
image: alpine
stage: test
script:
- test -f build/computer.txt
- grep "Mainboard" build/computer.txt
Possiamo definire delle variabili in questo modo
build laptop:
...
variables:
build_file_name: laptop.txt
script:
- echo "Mainboard" >> build/$build_file_name
Con lo stesso meccanismo possiamo definire anche variabili globali, che però è convenzione specificare in uppercase, come se fossero varabili d’ambiente.