Erreur de construction dans le serveur CI gitlab (peut-être lié aux sous-modules git)

Question

J'ai été affecté à un projet qui utilise des sous-modules git. Je l'ai fait un petit changement dans le démarquage du README.md et reçu l'erreur suivante:

Running on staging.example.com... 
Fetching changes... 
HEAD is now at 2414dbe test change 
From https://gitlab.example.com/external/project-example 
    2432dbe..b64b2d0 develop -> origin/develop 
Checking out b452d91 as develop... 
$ docker rm -f $CONTAINER_NAME-db 
Error response from daemon: No such container: project-example-db 
ERROR: Build failed: exit status 1 

Quand je vérifie le fichier nommé: .gitlab-ci.yml Je vois ce code:

# ADD 

install:clean: 
    stage: prepare 
    script: 
     - docker rm -f $CONTAINER_NAME-db 
     - docker rm -f $CONTAINER_NAME 
     - docker rmi $IMAGE_NAME 
    allow_failure: true 
    tags: 
     - staging 

# BUILD 

prepare:build: 
    stage: prepare 
    script: 
     - git submodule init 
     - git submodule update --recursive 
     - docker-compose build --no-cache --pull 
    tags: 
     - staging 

Je ne suis pas que si mon erreur est due à quelque chose qui manque avec les sous-modules, mon fichier .gitmodules ressemble à ceci:

[submodule "frontend"] 
    path = frontend 
    url = git@gitlab.example.com:external/project-example-frontend.git 
    branch = v3.1 

Je les 2 prises en pension (projet exemple & project-example-frontend) dans un répertoire. Qu'est-ce que je rate?

Answer 1

Vous essayez de supprimer les conteneurs projet par exemple db- et projet par exemple (en utilisant docker rm), tandis que projet-db exemple n'existe pas. Dans ce cas, la commande renvoie un état de sortie différent de zéro et le travail entier échoue. D'après les informations que vous avez fournies, il n'est pas complètement clair comment les conteneurs sont démarrés. Vous pouvez:

1. Check that the containers exist et de tenter de les supprimer uniquement s'ils le font.
2. Si les conteneurs sont démarrés avec docker-compose (dans le travail prepare:build), vous pouvez les supprimer avec docker-compose down au lieu de le faire avec élégance et ne pas échouer si les conteneurs ne sont pas en cours d'exécution.