Esecutore di finestra mobile Gitlab - immagine cache dopo before_script

Question

In gitlab-ci è disponibile un'opzione nel file .gitlab-ci.yml per eseguire comandi prima dell'esecuzione di uno qualsiasi degli script, denominata before_script. Gli esempi .gitlab-ci.yml illustrano l'installazione di programmi ausiliari qui. Tuttavia, quello che ho notato è che queste modifiche non sono memorizzate nella cache in Docker quando si utilizza un esecutore di finestra mobile. Avevo ingenuamente pensato che dopo aver eseguito questi comandi, la finestra mobile avrebbe messo in cache l'immagine, quindi per la prossima esecuzione o test, la finestra mobile caricherà solo l'immagine della cache prodotta dopo before_script. Ciò accelererebbe drasticamente le build.

A titolo di esempio, il mio .gitlab-ci.yml sembra un po 'come:

image: ubuntu 

before_script: 
    - apt-get update -qq && apt-get install -yqq make ... 

build: 
    script: 
     - cd project && make 

Una possibile soluzione è quella di andare alla macchina corridore e creare un'immagine finestra mobile che può costruire il mio software, senza alcuna altra installazione e quindi fare riferimento nella sezione image del file yaml. Lo svantaggio di questo è che ogni volta che voglio aggiungere una dipendenza, ho bisogno di accedere alla macchina del corridore e aggiornare l'immagine prima che le build avranno successo. Sarebbe molto più bello se dovessi aggiungere la dipendenza alla fine di apt-get install e fare in modo che la finestra mobile/gitlab-ci gestisca il caching appropriato.

C'è anche un comando cache in .gitlab-ci.yml, che ho provato a installare a untracked: true, che ho pensato che sarebbe in cache tutto ciò che non era un sottoprodotto del mio progetto, ma non sembrava avere alcun effetto.

C'è un modo per ottenere il comportamento che desidero?

Answer 1

Il modo in cui gestisco questo è che ho immagini personalizzate su Docker Hub per ciascuno dei nostri progetti e li riferimento da .gitlab-ci.yml. Se ho bisogno di una nuova dipendenza, modifico il Dockerfile usato per creare l'immagine iniziale, ricostruire l'immagine e taggarla usando un tag specifico e spingere a Docker Hub.

cat "RUN apt-get install gcc" >> Dockerfile 
ID=$(docker build) 
docker tag $ID ACCOUNT/gitlab_ci_image:gcc 
docker push ACCOUNT/gitlab_ci_image 

Poi ho aggiornare il file .gitlab-ci.yml per puntare a quella versione specifica dell'immagine.

image: ACCOUNT/gitlab_ci_image:gcc 

build: 
    script: 
     - cd project && make 

Questo mi permette di avere diverse dipendenze a seconda di quale impegno sto cercando di testare (come il file gitlab-ci.yml all'interno che commettono dice il corridore, che per l'uso). Impedisce inoltre la necessità di installare le dipendenze ogni volta che viene eseguito un test su un particolare corridore, in quanto il corridore riutilizzerà la stessa immagine purché non cambi.

L'altra cosa buona, è che con le immagini ospitate su Docker Hub, se il corridore ha bisogno di un tag specifico che non ha localmente, andrà a prendere automaticamente quello corretto in modo da poter avere 10 corridori e solo mantenere una singola immagine e questa manutenzione può essere eseguita sulla propria workstation o su qualsiasi macchina.

Personalmente ritengo che questa sia una soluzione molto migliore rispetto al tentativo di memorizzare nella cache qualsiasi cosa all'interno dell'immagine di un corridore. Questo è particolarmente vero quando crei un nuovo ramo per testare il tuo codice su una versione più recente di una dipendenza. Se avessi il caching avresti problemi con diversi ambienti di testing per le tue filiali di stable e dev. Inoltre, a mio parere, i test dovrebbero essere eseguiti all'interno di un ambiente il più pulito possibile e questa impostazione lo consente.

Answer 2

È possibile aggiungere uno stage per creare l'immagine al primo posto. Se l'immagine non ha alcun cambiamento, il palco sarà molto breve, meno di 1 secondo.

È possibile utilizzare quell'immagine nelle seguenti fasi, accelerando l'intero processo.

Questo è un esempio di un .gitlab-ci.yml:

stages: 
    - build_test_image 
    - test 

build_test: 
    stage: build_test_image 
    script: 
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY 
    - docker build -t $CI_REGISTRY_IMAGE:test -f dockerfiles/test/Dockerfile . 
    - docker push $CI_REGISTRY_IMAGE:test 
    tags: 
    - docker_build 

test_syntax: 
    image: $CI_REGISTRY_IMAGE:test 
    stage: test 
    script: 
    - pip install flake8 
    - flake8 --ignore=E501,E265 app/ 

Guarda il tag docker_build. Quel tag è usato per forzare l'esecuzione del palco sul corridore che ha quel tag. L'esecutore per quel corridore è shell e viene utilizzato solo per creare immagini Docker. Quindi, l'host in cui il corridore abita dovrebbe avere installato Docker Engine. Ho trovato che questa soluzione si adatta meglio alle mie esigenze rispetto alla finestra mobile nella finestra mobile e another solutions.

Inoltre, sto utilizzando un registro privato, è per questo che sto usando le variabili $CI_REGISTRY*, ma è possibile utilizzare DockerHub senza bisogno di specificare il registro. Il problema sarebbe quello di autenticarsi su DockerHub, però.