31. 변수 정의

 

## .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

  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're going to take a look at how you can define your own variables in Gittel website.

You probably have noticed that we now have this domain name all over the place here, so we now have

to insist on staging and this is defined in an environment and again here and again in testing and so

on.

So definitely every time you have something that you have to duplicate all over the place, and especially

with something that can change.

It is generally not a good idea to replicate it all over.

And here comes the concept of variables.

Now, if we remember all variables, we have used variables in the past and we have to use them actually

to start to cigarettes.

And as you remember, you can configure your own variables if you go to settings ICD and go over to

variables.

I previously said that this is a good idea to store your secrets here.

Now, it doesn't mean that you can only store secrets here.

So like the search, login and search token, you can actually store anything that you like.

And one idea would be to store the domain names here and you can definitely do that and then simply

reference them in the scripts.

This will keep the configuration of your pipelines or the name of the remains separated from your code,

from your code base.

But you can define these variables in your pipeline and maybe later decide what you want to do with

them, which one is, in your case, the best approach.

Nevertheless, I think we can agree that it is not a good idea to duplicate stuff.

So in this lecture, I'm going to show you how you can define variables in your catalepsy pipeline.

Now, as with many things, you can define variables either directly in your job so that you can reuse

something in your job.

For example, if I would put this in a variable, then I could use it here and here.

But as this is needed later, at least for the production is listed here in order to run the production

test, it definitely makes sense to define this on a global level.

Well, let's go here and define variables.

And I'm going to keep it very simple, I'm going to name it staging domain.

And production domain.

Of course, you are totally free to name them as you like.

So let's go and change our configuration as well.

And for production.

Now we need to change it here as well.

So now we have the staging domain and a production domain and hopefully we don't have anything with

search anymore in our code.

OK, so these are the only two occurrences.

Now, the good news is that if you decide to move them outside your normal configuration file, you

can easily do so or otherwise.

If you need to change these domains, you can do that as well from here quite easily.

So let's committees and see if our pipeline still works the same.

So it seems that everything works perfectly because the pipeline still runs, actually, because we

have all this test, especially in our case, the production test, we can actually make sure that the

changes that we make to the pipeline, especially when it comes to configuration stuff, that they actually

work and they give us this feeling that much whatever we do with the pipeline, we still have a working

and functional pipeline.

So this is how you can use variables for your domain names or for everything or for anything else that

could actually change.

And as I said, the indicator for such things that need to be in a variable is when you start repeating

yourself and you start adding configuration and putting something in a lot of places in your getler

configuration file.