Getting started: Create and run your first Gitlab CI/CD pipeline

Hai semuanya, sekarang kita akan mencoba menggunakan Gitlab CI/CD pipeline. Tetapi ada beberapa prerequisites yang harus dipenuhi diantaranya:

Before you start, make sure you have:

• A project in GitLab that you would like to use CI/CD for.
• The Maintainer or Owner role for the project.

To create and run your first pipeline:

• Ensure you have runners available to run your jobs. To view available runners: Go to Settings > CI/CD and expand Runners.
• If you’re using gitLab.com, you can skip this step. gitLab.com provides shared runners for you. If you don’t have a runner
  1. Install GitLab Runner on your local machine.
  2. Register the runner for your project. Choose the shell executor.
• Create a .gitlab-ci.yml file at the root of your repository. This file is where you define the CI/CD jobs.

When you commit the file to your repository, the runner runs your jobs. The job results are displayed in a pipeline.

Okay karena pembahasan kali ini akan lumayan panjang, jadi kita akan bagi-bagi menjadi beberapa bagian diantaranya seperti berikut:

1. Create a .gitlab-ci.yml file
2. Running the Gitlab CI pipelines
3. Tips for writing the .gitlab-ci.yml

Create a .gitlab-ci.yml file

File .gitlab-ci.yml basiclly it’s a YAML format that you can specify to instruction of Gitlab CI/CD. in this file, you can define:

• The structure and order of jobs that the runner should execute.
• The decisions the runner should make when specific conditions are encountered.

To create a .gitlab-ci.yml file you can used:

• Manually, by using text-editor such as vscode, vim, nodepad, etc

• Build-in text-editor by gitlab

  This example shows four jobs: build-job, test-job1, test-job2, and deploy-prod. The comments listed in the echo commands are displayed in the UI when you view the jobs. The values for the predefined variables $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH are populated when the jobs run.

• Then submit, commit & push

Now take a look at your pipeline and the jobs within.

1. Go to CI/CD > Pipelines. A pipeline with three stages should be displayed:

   

2. View a visual representation of your pipeline by selecting the pipeline ID:

   

3. View details of a job by selecting the job name.

   • This is build-job

   • This is build-test2

   • This is build-deploy-prod

You have successfully created your first CI/CD pipeline in GitLab. Congratulations!

Now you can get started customizing your .gitlab-ci.yml and defining more advanced jobs.

Running the Gitlab CI pipelines

By default, when you push or changed the file of .gitlab-ci.yml it’s trigger pipeline to run, but we have an other way to run it. Here is 4 deffrent method to the run pipeline:

• Workflow (rules, only)
• Manually run pipeline
• Schedule to run pipeline
• Trigger using (webhook, rest-api)

Updating file .gitlab-ci.yml

Okay kita bahas satu-per-satu, mulai dari update file .gitlab-ci.yml yang sebelumnya seperti berikut:

Ketika di push maka secara otomatis akan jalan pipeline baru seperti berikut:

The output will print look like this:

Hello, my name is Dimas Maryanto ! \n i'm trying to learn CI/CD feature with Gitlab CI

Using workflow

Sekarang kita coba untuk workflow method, dengan mengupdate file .gitlab-ci.yml menggunakan property only atau rules seperti berikut:

Ketika di push maka secara otomatis akan jalan pipeline baru dan berikut adalah pipeline detailnya:

Nah terlihat disana terdapat 3 job yaitu build-job, test-job2 dan deploy-prod. Terus untuk job test-job1 kemana?

Job test-job1 hanya akan muncul jika kita membuat branch, tags atau commit message dengan prefix -release seperti berikut:

Kita coba buat tag 2023.06.18.12.51-release pada branch `main seperti berikut:

Sekarang jika kita lihat pada pipeline detail yang terbaru maka jobnya jalan seperti berikut:

Dengan dengan membuat tag tersebut, kita menjalankan kembali job sebelumnya beserta test-job1 tetapi tanpa job deploy-prod

Sedangkan untuk menjalankan yang job build-prod kita bisa membuat Merge request dari branch dengan prefix hotfix/ ke branch default yang which is main.

• Buat branch baru misalnya dengan nama hotfix/issue01 dari branch main
• Buat perubahan dan commit serta push
• Buat merge request ke main maka hasilnya seperti berikut:

Manually run pipeline

Selain menggunakan script based, dan workflow Gitlab CI kita juga bisa menjalankan pipeline secara manual dengan click Run pipeline pada menu Pipelines seperti berikut:

Kemudian muncul form seperti berikut, jika tidak ada option yang kita define pada script .gitlab-ci.yml just click the button, hasilnya seperti berikut:

Schedule to run pipeline

Lanjutan dari run pipeline secara manual tersebut, kita juga bisa meng-schedule pipeline dengan menggunakan cron pattern caranya

• Akses ke menu Pipelines -> Schedule seperti berikut:

  

• Misalnya kita mau menjalankan pipeline tersebut setiap 5 menit, jadi pilih Interfal pattern Custom input seperti berikut */5 * * * *

• Kemudian save, seperti berikut:

Dan perhatikan ke menu Pipeline 5 menit mendatang hasilnya seperti berikut:

Trigger using (webhook, rest-api)

Yang terkahir kita juga bisa me-trigger dari Webhook atau Rest-API menggunakan tools seperti curl atau bahkan Postman. Untuk membuat Gitlab CI yang bisa di triger kita membuat dulu TOKEN di menu Settings -> CI/CD -> expand Triger pipeline seperti berikut:

Kemudian input nama/description contohnya trigger-curl dan kemudian click button Add triger maka akan muncul tokennya, coba simpan token tersebut.

Setelah itu kita bisa triger pipeline dengan perintah curl berikut:

curl -X POST \
     --fail \
     -F token=TOKEN \
     -F ref=REF_NAME \
     PROTOCOL://SERVER_GITLAB/api/v4/projects/PROJECT_ID/trigger/pipeline

Sekarang coba jalankan perintah berikut di terminal

➡ curl -X POST \
     --fail \
     -F token=glptt-da5dbea331d2c78071752e4528ba52c34a9a9567 \
     -F ref=main \
     https://gitlab.dimas-maryanto.com/api/v4/projects/364/trigger/pipeline

{
  "id": 1029,
  "iid": 12,
  "project_id": 364,
  "sha": "93b7c2cfda83cda7b42bea5619c2756f7e57022e",
  "ref": "main",
  "status": "created",
  "source": "trigger",
  "before_sha": "0000000000000000000000000000000000000000",
  "tag": false,
  "yaml_errors": null,
  "user": {
    "id": 2,
    "username": "dimasm93",
    "web_url": "https://gitlab.dimas-maryanto.com/dimasm93"
  },
  "detailed_status": {
    "icon": "status_created",
    "details_path": "/examples/gitlab-ci-cd/test-gitlab-ci/-/pipelines/1029"
  }
}

Sekarang kita lihat hasilnya:

Tips for writing the .gitlab-ci.yml

Here are some tips to get started working with the .gitlab-ci.yml file.

For the complete .gitlab-ci.yml syntax, see the full .gitlab-ci.yml keyword reference.

• Use the pipeline editor to edit your .gitlab-ci.yml file.

• Each job contains a script section and belongs to a stage:
  • stage describes the sequential execution of jobs. If there are runners available, jobs in a single stage run in parallel.
  • Use the needs keyword to run jobs out of stage order.
• You can set additional configuration to customize how your jobs and stages perform:
  • Use the rules keyword to specify when to run or skip jobs. The only and except legacy keywords are still supported, but can’t be used with rules in the same job.
  • Keep information across jobs and stages persistent in a pipeline with cache and artifacts. These keywords are ways to store dependencies and job output, even when using ephemeral runners for each job.
  • Use the default keyword to specify additional configurations that are applied to all jobs. This keyword is often used to define before_script and after_script sections that should run on every job.

Back to top ↑