Reputation: 3
In first time I encountered a malfunction when retrying a older pipeline with 4 stages and 1 jobs each, when pipeline is retried only step 4 and step 1 as run
my .gitlab-ci.yml
stages: - build - deploy - clean before_script: … variables: GIT_SUBMODULE_STRATEGY: recursive GIT_STRATEGY: clone build: stage: build script: - git submodule init - git submodule update -f allow_failure: false when: manual only: - master production: stage: deploy script: - ssh $DEPLOY_SERVER_USER@$DEPLOY_SERVER_ADDRESS "[ -f /usr/bin/rsync ] || apt-get install -qq -y rsync && [ -f /usr/bin/getfacl ] …. » allow_failure: false rollback: stage: clean script: - ssh $DEPLOY_SERVER_USER@$DEPLOY_SERVER_ADDRESS "[ -d /var/www/old/ ] … exit 1" when: on_failure allow_failure: false cleanup: stage: clean script: - ssh $DEPLOY_SERVER_USER@$DEPLOY_SERVER_ADDRESS "rm -rf /var/www/old && rm -rf /var/www/new && rm -rf /var/www/acl" when: on_success allow_failure: false
Or would it not be more logical in my git workflow to revert my master to the desired commit?
Upvotes: 0
Views: 1257
Reputation: 1435
Yes, the correct way is to revert the code first and run the pipeline again.
but in some cases we don't have time to fix the code and we need to do an emergency rollback.
but looking at your pipeline, your step build is useless.
You need to move the git submodule
commands to the other steps too, because the other jobs are using only you raw code without the content of the submodule
Upvotes: 0