32. 수동 배포 / 수동으로 작업 트리거

 

 

 

 

 

https://docs.gitlab.com/ee/ci/yaml/#whenmanual

Keyword reference for the `.gitlab-ci.yml` file | GitLab

 

https://docs.gitlab.com/ee/ci/yaml/#allow_failure

Keyword reference for the `.gitlab-ci.yml` file | GitLab

 

 

 

 

 

 

allow_failure

allow_failure작업이 실패할 때 파이프라인을 계속 실행해야 하는지 여부를 결정하는 데 사용 합니다.

• 파이프라인이 후속 작업을 계속 실행하도록 하려면 를 사용 allow_failure: true합니다.
• 파이프라인이 후속 작업을 실행하지 못하도록 하려면 를 사용 allow_failure: false하십시오.

 

## .gitlab-ci.yml

 

image: node

stages:

  - build

  - test

  - deploy staging

  - deploy production

  - production tests

cache:

  key: ${CI_COMMIT_REF_SLUG}

  paths:

    - node_modules/

variables:

  STAGING_DOMAIN: aido-stg.surge.sh

  PRODUCTION_DOMAIN: aido-pro.surge.sh

build website:

  stage: build

  script:

    - echo $CI_COMMIT_SHORT_SHA

    - npm install

    - npm install -g gatsby-cli

    - gatsby build

    - sed -i "s/%%VERSION%%/$CI_COMMIT_SHORT_SHA/" ./public/index.html

  artifacts:

    paths:

      - ./public

test artifact:

  image: alpine

  stage: test

  script:

    - grep -q "Gatsby" ./public/index.html

test website:

  stage: test

  script:

    - npm install

    - npm install -g gatsby-cli

    - gatsby serve &

    - sleep 3

    - curl "http://localhost:9000" | tac | tac | grep -q "Gatsby"

deploy staging:

  stage: deploy staging

  environment:

    name: staging

    url: http://$STAGING_DOMAIN

  script:

    - npm install --global surge

    - surge --project ./public --domain $STAGING_DOMAIN

deploy production:

  stage: deploy production

  environment:

    name: production

    url: http://$PRODUCTION_DOMAIN

  when: manual

  allow_failure: false

  script:

    - npm install --global surge

    - surge --project ./public --domain $PRODUCTION_DOMAIN

production tests:

  image: alpine

  stage: production tests

  script:

    - apk add --no-cache curl

    - curl -s "https://$PRODUCTION_DOMAIN" | grep -q "Hi people"

    - curl -s "https://$PRODUCTION_DOMAIN" | grep -q "$CI_COMMIT_SHORT_SHA"

 

 

 

============================================

 

In this lecture, we are going to take a look at how you can configure specific jobs to be triggered

manually only.

So let's take a moment to revisit our continuous deployment pipeline, and as you remember, we said

that until the changing environment, we can do everything automatically.

So we deploy on other environments and we have that already.

We have only the staging environment, but everything is going automatic is said.

We want to have like a manual review process.

We don't want to go to production automatically as we do right now.

We want to have somebody manually triggering a deployment, eventually looking what's on staging.

Is this something that don't want to have on production as well?

And as you have seen so far, this goes automatically in Gottleib.

You'll nobody ask you if you want to deploy to production, it just deploys.

So as long as that staging environment works and any other stages before, it just goes to production.

So what we will do in this lecture, we are going to get this manual intervention step so that we deploy

to production only when we mentally decide that this is what we want.

So for that, we're going to edit our pipeline and the job that we want to change is actually deployed

to production.

So the additional configuration that we can edit here is to add a when.

And to say, Manuel.

So this specific job will only be triggered when we manually click into the interface and I'll be able

to show you how exactly this works after I commit and let the pipeline run.

So if you now take a look at our pipeline, you will see that deploy production looks a bit different

and it hasn't been executed.

But what's surprising a bit is that next, the stage production test has been executed.

And, of course, because the wrong version is still available online, the test in this case failed.

But we'll fix that a bit later.

So what we wanted to achieve is actually to not allow a deployment on production without first checking

to see what's going on.

We can even go again back to environments.

And you will be able to see that staging and production have different versions, so you will see a

different committee hashes, which is consistent with what we see in our pipeline.

So this all indicates that we haven't done a production deployment yet.

So let's go ahead and do it.

I'm going to open the pipeline again.

And all I need to do is simply click on this job.

And now it will start the deployment.

And a few moments later, deploy to a production has been successful as well, but we still see that

the production tests are failing now.

They haven't been started again, and we can manually fix them by clicking the retry button and see

if the deployment now is successful.

Now, the production tests have passed as well.

And now the entire pipeline is successful.

Now, of course, the way it is right now isn't really the way we would like to have, because the normal

expectation would be if you introduce here a manual step, that the rest of the stages won't be executed.

And unfortunately, this is not the default behavior in Getler, but we still have the possibility of

changing that.

So let's go back to our code editor and make a small change.

Now, what is actually missing in order to get the behavior that you want so that we can wait after

this manual stage and not execute a production test is to add the following line.

And this is a low on this car failure, false.

And all this is not very intuitive.

And I will include the official documentation on this one.

But this should fix our problem.

So let's see if it works as we expect.

Now, if we look again at our pipeline, you will see that the status is blocked, so let's go ahead

and see how it looks now.

So it seems that the change that we have done works properly, because you can see deployed production

hasn't been executed yet and waits for the manual action and the production tests are waiting for the

previous stage.

So it looks all good.

I'm going to deploy now.

And the production test will be started right after this.

So this is how you can implement a continuous delivery pipeline with manual actions or any other manual

actions that you need inside your pipeline.

So just a short recap, what we have done is to add this additional condition for the Duplo production

job when Manuell and because we had additional stages after this stage that we wanted to block, we

added this additional condition, allow failure, which makes which blocks basically the entire pipeline

waits for our manual action and only then executes the rest of the stages.

Now, we won't need this anymore, so for that reason, I will remove it from the pipeline and we'll

continue doing continuous deployments to production.