39장. Destroying environments (Clean-up after the Merge Request)

 

## Master 로 Merge 진행시, 기존 Branch의 테스트 주소 삭제 작업 진행

 

 

 

 

 

 

 

## .gitlab-ci.yml

 

image: node

stages: 
  - build
  - test
  - deploy review
  - 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
  only:
    - master
    - merge_requests  
  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
  only:
    - master
    - merge_requests
  script:
    - grep -q "Gatsby" ./public/index.html

test website:
  stage: test
  only:
    - master
    - merge_requests
  script:
    - npm install
    - npm install -g gatsby-cli
    - gatsby serve &
    - sleep 3
    - curl "http://localhost:9000" | tac | tac | grep -q "Gatsby"

deploy review:
  stage: deploy review
  only:
    - merge_requests
  environment:
      name: review/$CI_COMMIT_REF_NAME
      url: https://aido-$CI_ENVIRONMENT_SLUG.surge.sh
      on_stop: stop review      
  script:
    - npm install --global surge
    - surge --project ./public --domain aido-$CI_ENVIRONMENT_SLUG.surge.sh

stop review:
  stage: deploy review
  only:
    - merge_requests
  variables:
    GIT_STRATEGY: none
  script:
    - npm install --global surge
    - surge teardown aido-$CI_ENVIRONMENT_SLUG.surge.sh
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop

deploy staging:
  stage: deploy staging
  environment:
    name: staging
    url: http://$STAGING_DOMAIN
  only:
    - master
  script:
    - npm install --global surge
    - surge --project ./public --domain $STAGING_DOMAIN

deploy production:
  stage: deploy production
  environment:
    name: production
    url: http://$PRODUCTION_DOMAIN
  only:
    - master  
  # when: manual
  # allow_failure: false
  script:
    - npm install --global surge
    - surge --project ./public --domain $PRODUCTION_DOMAIN

production tests:
  image: alpine
  stage: production tests
  only:
    - master
  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"

 

 

 

 

 

 

https://surge.sh/help/tearing-down-a-project

 

 

 

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

 

With this new future of dynamically using and creating environments, we have created a problem as well.

And once the branch has been merged, there's actually no need to keep that environment running.

And by default, it will still continue to run.

And we have the possibility of stopping it.

But this will not actually do anything because we haven't really instructed Gottleib Lab on how to stop

the environment.

And this is exactly what we're going to do in this lecture.

We are going to look into how we can stop the environment as soon as we don't need them anymore.

From a technical point of view, the problem that we have is that we have instructed Surge to create

this domain and we have deployed the files there and we need a way to tell Sergej, hey, we don't need

this anymore.

And luckily, there's a HelpAge on search explaining us how we can destroy your projects or how we can

turn down a project in the command for that is quite simple.

We simply specify search teardown down and then we specify where it is.

But what is the name of the address?

So let's go back to our configuration and create a job that will turn down a published project.

So let's start with the following configuration.

Now, the name of the job is Stop Review, and it's still part of the stage diploid review.

We want to run this stop review job when the branch has already been merged and possibly deleted as

we have configured, so for that reason, we need to specify here a good strategy and this is needed

so that this job doesn't try to clone this specific branch, which may no longer exist.

And the way you specify this is by defining this strategy variable.

And we are going to set it to none.

As you see, it is variable is defined only inside this job and only has an effect for this job.

Good strategy is a variable that kid Lapkin understand.

And if we set it tanon, it will not clent this repository.

Now, from the scripting point of view, there are a couple of things we need to do.

You still need to globally install search.

So I'm going to replace this.

And as you have seen, we need to use surge here down and then we need to specify the domain name.

Additionally, we need to establish a link between diploid review and stop review, and we do it by

additional configuring the environment and we are going to sit here on stop.

This will be stop review because this is the name of the job.

OK, so let's go ahead and create a new branch and see how this performs.

Now, the pipeline for much request has executed.

Let's take a look at it.

You notice that not much has changed.

We still have the three stages and this job that was supposed to stop the review system doesn't really

show up in this pipeline, not first of all, let's open the website and see that it works.

Again, this is another address that has been dynamically generated, but everything works just fine.

Now, we could go ahead and manually stop the environment here, but this will be an additional manual

step that we do not want to do.

We want to let Getler do this for us when we march and delete this brunch.

So let's click on March and see what happens.

Initially, not much has happened, but let's now take a moment to inspect the pipeline for the monster

branch.

And you will see here that it now has the build and the test stages that we already know, and it has

the Deepthi review stage as well.

And actually this is happening because we have forgotten to do something.

I've forgotten to exclude this from Uster.

And yeah, diploid review is part of the pipeline and it has a job.

And this is why it has decided to have this job here.

This is definitely not OK.

So I'm going to quickly go ahead and fix this and we're going to take a second look at this.

So what we actually want for the stop preview as well is to get this only flag.

So that it only works for much requests.

This is what has been missing, and for that reason, he has showed up on the massive pipeline.

A pipeline for the project is not successful, and we click this link, we can easily inspect the app

that we have deployed.

Now, let's go ahead and watch this and see what happens.

Now, you will see that as soon as we have marched to branch, this has started, the pipeline for this

branch has started again.

And if you take a closer look at it, you will see that diplo review has been deployed and this is working

and now Stop Review has started doing its job and this has been automatically triggered by Gottleib.

As I have said, you can manually trigger this as well.

But we were definitely interested in letting get laboratory goodies for us.

Now we can see that star preview was successful, so.

If we go now back to the website and hit the refresh, we should no longer see diSEMBOWELMENT.

And this is how it looks like project not found.

So basically.

Everything has worked as we have expected, so let's go back to the project configuration and review

again what we have done.

Now, we have added another job called Stop Review, and the way we have linked this is that by diploid

review, when specifically the environment we have added on stop and we are referencing stop review

now, stop review is triggered manually and it will not run automatically when the pipeline runs.

And this is why when manual is needed.

Now, manual doesn't mean that Getler cannot trigger it.

So for that reason, this is like a semi manual thing where when we are deleting the branch, when we

are merging, our request actually get can point a finger at a stop button and will trigger this, but

otherwise this will not get triggered.

Additionally, there are things that we need to have here.

So we need to have this environment and the name of the environment must match the name of the environment

we are trying to stop.

So if there's any mismatch there, this will not work.

And again, here, the action needs to be stopped.

And apart from this, we have added this strategy so that we do not take out any files.

And this is simply the script that is actually tearing down the environment.

So there are a few rules that we need to follow in order to make it work as Kit expects it to work.

So this is why all this extra configuration around it.