40장. before_script 및 after_script 구성

 

## before_script 선택적 옵션

 

 

 

 

 

 

 

 

 

 

 

 

 

## .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
  before_script:
    - echo "Deploying to Production"
    - npm install --global surge
  script:
    - 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"

 

 

 

 

 

 

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

 

This like you don't want to talk about it before script and after script configuration that you can

do in catalepsy now, starting with before script, before script is often used to define a command

that should run before the main script runs.

Now, you can define it at the global level or you can define it as the job level.

Overriding the default configuration, the global configuration that you have, for example, that we

can do is to add here and not before deploy production.

You can add your own before script.

And they call applying to production.

Now, this will be executed before the main block script is executed.

Why would you want to do that?

You are not forced to use it.

You can use it.

If you find a scenario where running either a script globally before the script is being executed makes

sense, or if you have something globally and you need to override it, that would be a possibility

as well.

What you will often seen some configurations, if you are looking at configurations that others have

written for Forget Besigye, is that they install any dependencies that are needed for the specific

job in the before script block.

So, for example, in this case, we are installing Serj because we want to deploy something with search.

Now, of course, this entire script blocker isn't that big, but sometimes the tools that need to be

installed in order to run something can occupy a few lines.

And what you can use before script is to make a separation between what is the actual script about.

So, for example, in this case, we are simply deploying this project.

So this is like the main functionality and the rest of it.

For example, this installation, this is only need for this Destrehan.

So what we can do is that we can move it to before script.

And now if you look at the main script, it's simply script to call it that way, you can easily say,

OK, in this step, this is what is being done.

And the script is just like the set up in order to make everything work.

And this can make your entire pipeline configuration easier to read.

Now, if you want to use it or not, this is totally up to you.

I just wanted to present you before this is something that you will see more often if the script runs

a bit differently because the working directory will be set to default.

And a context where the script around is totally different from before script and the script blocks.

And for that reason, they have nothing to an example but all the documentation.

And just to keep this in mind, before script after script exists, if you ever have the need of using

them, feel free to check the configuration.

It's much better.

And for the rest of the scenario, we'll leave this as it is.

So I'm going to reverse these changes and we'll leave everything in the script and will not use before

script.