CI/CD and GitLab implementations

Page content

Definitions of CI/CD (rough)

https://docs.gitlab.com/ee/ci/introduction/

  • CI (Continuous Integration): Building and testing codes are automated.
  • CD
    • Continuous Delivery: One-click deploy enabled.
    • Continuous Deployment: Auto deploy enabled.

Facts about GitLab implementation

  • GitLab Runner is an environment in which the CI/CD scripts run.
  • We write the procedures in the file .gitlab-ci.yml normally.

You need a GitLab Runner first.

Install and configure a Runner

Please refer my GitLab Runner install post :)

How to write .gitlab-ci.yml - your own GitLab instance

Official tutorial: https://docs.gitlab.com/ee/ci/quick_start/

  • At the top of the YAML structure, we write “job"s with arbitrary name (my_job_1 in the following example).
  • “Tag"s indicates to selcet a runner.
  • In a job, we can write “script” to be running.

.gitlab-ci.yml

my_job_1:
  tags:
    - runner1
  script:
    - echo "What a nice day!"

my_job_2:
  tags:
    - runner1
  script:
    - echo "Tommorow would be better than today."

How to write .gitlab-ci.yml - public GitLab

If you want to use public GitLab CI/CD runner, omit tags fields. As of April 2022, you need a credit card information to reduce an abuse of public GitLab CI/CD.

Check the result

Go Your Project -> CI/CD

  • Pipeline: The entire CI/CD process.
  • In the specific pipeline page, you can see there are independnet jobs my_job_1 and my_job_2.
  • In Jobs page, you can see execution log. Here is my example.
Running with gitlab-runner 13.9.0 (2ebc4dc4)
  on A shared GitLab Runner for {{ my_GitLab_domain}} xy-ABCDE
Preparing the "docker" executor
00:05
Using Docker executor with image alpine:3.13 ...
Pulling docker image alpine:3.13 ...
Using docker image sha256:28f6e27057430ed2a40dbdd50d2736a3f0a295924016e294938110eeb8439818 for alpine:3.13 with digest alpine@sha256:a75afd8b57e7f34e4dad8d65e2c7ba2e1975c795ce1ee22fa34f8cf46f96a3be ...
Preparing environment
00:01
Running on runner-xy-abcde-project-5-concurrent-0 via {{ my_GitLab_Runner_domain}}...
Getting source from Git repository
00:00
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/{{ my_GitLab_username }}/{{ my_repository_name }}/.git/
Created fresh repository.
Checking out 0520e589 as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:01
Using docker image sha256:28f6e27057430ed2a40dbdd50d2736a3f0a295924016e294938110eeb8439818 for alpine:3.13 with digest alpine@sha256:a75afd8b57e7f34e4dad8d65e2c7ba2e1975c795ce1ee22fa34f8cf46f96a3be ...
$ echo "What a nice day!"
What a nice day!
Cleaning up file based variables
00:00
Job succeeded

We can define “stage"s also. Note that the default value of stage is test.

More configurations

Let’s focus on single job, and configure more details. You can find the whole list of keywords at here.

Specify runtime container

default:
  image: rust:1.60-alpine3.15

job_1:
  stage:
  script:
    - echo "What a nice day!"
    - cargo --version

Several stages

stages:
  - my_build
  - my_test
  - my_deploy

job1:
  stage: my_build
  script:
    - echo "This job compiles code."

job2:
  stage: my_test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  stage: my_test
  script:
    - echo "This job also runs in the test stage".

job4:
  stage: my_deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  • stages list also decides order of stages.
  • If multi jobs are belong to the same stage, runner try to run in parallel.
  • GitLab clones Docker container every time you run a new job.

Variables

variables:
  DEPLOY_SITE: "https://atlex00.com/"

my_build_job:
  stage: build
  script:
    - echo $DEPLOY_SITE

my_deploy_job:
  stage: deploy
  variables:
    SPECIAL_PATH: "/review"
  script:
    - echo SPECIAL_PATH is $SPECIAL_PATH

Comment out

https://docs.gitlab.com/ee/ci/jobs/#hide-jobs

# is normal way, or, append a dot . can also comment out the job.

Conditional CI/CD

rules: https://docs.gitlab.com/ee/ci/yaml/index.html#rules

Furthur

https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html

Anchors

.my_job: &my_job and <<: *my_job.

Anchors YAML has a feature called ‘anchors’ that you can use to duplicate content across your document.

Use anchors to duplicate or inherit properties. Use anchors with hidden jobs to provide templates for your jobs. When there are duplicate keys, GitLab performs a reverse deep merge based on the keys.

To be written: run Ansible playbook in CI/CD

Here is a sample Ansible playbook.

---
- name: Test Playbook
  gather_facts: false
  hosts: your-own-host.com
  tasks:
    - name: Echo in Ansible
      shell:
        cmd: echo "I'm in a playbook!"