Skip to main content

Unit 1 - Introduction to GitLab

About 5 minGitlabcrashcourseyoutubefreecodecampvdespagitlabyamlcicdcicd

Unit 1 - Introduction to GitLab κ΄€λ ¨

1.1 Welcome

  • this course is for people new to DevOps who want to use GitLab to build, test and deploy their software
  • you will get hands-on experience building pipelines with GitLab CI and deploying software to AWS
Valentin Despa | @vdespa
Subscribe to my YouTube channel

1.2 Your first GitLab project

  • we will be using GitLab.com in this course
  • create a free GitLab.com account
  • by default, you will get a free trial, and your account will be downgraded to a free one after 30 days
  • change the theme: [Profile] > [Preferences] > [Syntax highlighting theme] > [Monokai]
  • Enable Render whitespace characters in the Web IDE
  • GitLab CI pipelines are defined in a file called .gitlab-ci.yml
test:
  script: echo "Hello world"
  • to run your pipeline using the GitLab.com infrastructure, you need to verify your account with a credit card
  • validation troubleshooting:
    • Validation is stuck. Nothing happens. If the interface is stuck or loading after 2-3 minutes of waiting, open a new tab and return to your main project page. If you don't see the message that you need to validate your account, it could mean that the validation was successful.

1.2.a πŸ“š Resources

1.3 Your first pipeline

  • when we build and ship software, we need to follow a series of steps
  • we define the GitLab CI pipeline using YAML
  • a job can execute one or multiple commands
  • mkdir build - creates a new folder called build
  • touch file.txt - creates a new file called file.txt
  • >> is called a redirection operator and appends the output from a previous command to a file
  • cat can be used for displaying the contents of a file
  • use Linux Alpine for this job because it is a very lightweight distribution
  • if no stage is defined in the job config, the test stage will be assigned
  • a pipeline is composed of a series of jobs organized in stages
Pipeline after this lecture .gitlab-ci.yml
build laptop:
  image: alpine
  script: 
    - echo "Building a laptop"
    - mkdir build
    - touch build/computer.txt
    - echo "Mainboard" >> build/computer.txt
    - cat build/computer.txt
    - echo "Keyboard" >> build/computer.txt
    - cat build/computer.txt

1.4 Help, my pipeline is not working

  • here are some common mistakes that lead to errors in the jobs:
    • no space after -, like -echo "Foo"
    • bad indentation
    • forgetting to add column : after stages: , build: , script:

1.4.a πŸ“š Resources

1.5 What is YAML?

  • you need to know some YAML basics to write GitLab CI pipelines
  • YAML is somewhat similar to JSON or XML
  • XML, JSON and YAML, and human-readable data interchange formats
  • YAML is being often used for storing configurations

1.6 What is a shell?

  • we typically run commands such as echo, touch, mkdir, cat and so on through a command-line interface or CLI
  • to automate the building & releasing of software, we rely on tools that have no UI, so we need to use the CLI

πŸ“š Resources

1.7 GitLab architecture

  • at a minimum, the GitLab architecture contains the GitLab Server (also known as the coordinator) and a GitLab Runner
  • the GitLab server manages the execution of the pipeline and its jobs and stores the results
  • when a job needs to be executed, the GitLab server will find a runner to run the job
  • a runner is a simple program that executes a job
  • a working GitLab CI setup must have at least one runner, but there are often more of them to help distribute the load
  • there can also be specific runners that have a particular software or hardware configuration (this is outside of the scope of this course)
  • this is a simplified overview of the steps involved when a job is executed:
    • the GitLab server (coordinator) locates a GitLab Runner and sends instructions for running the job
    • the GitLab Runner will pull the Docker image specified in the job configuration (or the default image if no Docker image is specified)
    • the GitLab Runner will start the Docker container
    • the GitLab Runner will get the files stored in the Git repository
    • the GitLab Runner run the commands from the script keyword inside the Docker container
    • the GitLab Runner report back to the GitLab server (coordinator) the results of the job execution
    • the GitLab Runner will terminate the Docker container

Docker in 100 Seconds

πŸ“š Resources

1.8 Pipeline stages

  • by default, a job will be assigned to the Test stage
  • if two or more jobs belong to the same stage, they will be executed in parallel
  • the stages: keyword allows us to define the stages of the pipeline
  • the keyword stage: allows us to associate a job with a stage
Pipeline after this lecture .gitlab-ci.yml
stages:
  - build
  - test

build laptop:
  image: alpine
  stage: build
  script: 
    - echo "Building a laptop"
    - mkdir build
    - touch build/computer.txt
    - echo "Mainboard" >> build/computer.txt
    - cat build/computer.txt
    - echo "Keyboard" >> build/computer.txt

test laptop:
  image: alpine
  stage: test
  script:
    - test -f build/computer.txt

1.9 Why do pipelines fail?

  • CLI programs indicate if their execution was successful or not by returning an exit code
  • an exit code 0 will indicate that a program has been executed successfully
  • any other exit code, which can be from 1 to 255, indicates failure
  • if GitLab detects a non-zero exit code, the job execution stops
  • Highly important tip: reading the job logs from top to bottom is KEY to understanding WHY a job has failed

1.10 Job artifacts

  • every job is executed in a separate container, so by default, no files are shared
  • to save the build results, we need to define the file(s) or folders as artifacts
  • in GitLab, we do this by using the artifacts keyword:
build laptop:
  ...
  artifacts:
    paths:
      - build
Pipeline after this lecture .gitlab-ci.yml
stages:
  - build
  - test

build laptop:
  image: alpine
  stage: build
  script: 
    - echo "Building a laptop"
    - mkdir build
    - touch build/computer.txt
    - echo "Mainboard" >> build/computer.txt
    - cat build/computer.txt
    - echo "Keyboard" >> build/computer.txt
  artifacts:
    paths:
      - build

test laptop:
  image: alpine
  stage: test
  script:
    - test -f build/computer.txt

1.11 Testing the build

  • our goal is to automate both the build process and the test process
  • currently, we are only testing the content of the file by downloading the job artifacts or by using the cat command
  • to automate the testing process, we will use the grep command
  • grep allows us to search for a specific string in a file.
        - grep "Display" build/computer.txt
  • tests play a very important role in automation
  • you need to "test" the tests, to ensure that they will fail if needed

1.12 Variables

  • we prefer to use variables instead of repeating a string in the pipeline configuration
  • variables can be defined in scripts or using the variables: keyword
  • to reference the variable, we use the dollar sign before it
variables:
  BUILD_FILE_NAME: laptop.txt
  • variables can be defined locally in the job or globally for all jobs
  • when using spaces or some special characters, you may need to put the entire value between quotes

1.13 What is DevOps

  • DevOps is not a standard and does not have an universally agreed definition
  • DevOps is not a standard or a tool, but a set of practices
  • DevOps uses automation to that help us build successful Products
  • DevOps requires a different mindset and works really well with Agile & Scrum

πŸ“š Resources

이찬희 (MarkiiimarK)
Never Stop Learning.