0
votes

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?

1

1 Answers

0
votes

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