𝓓𝓻-𝓛𝓲𝓷𝓾𝔁𝓮𝓻 𝓑𝓵𝓸𝓰
Working With Artifacts In GitLab CI/CD Pipeline

Working With Artifacts In GitLab CI/CD Pipeline

Aung Aung Myo Myint's photo
Aung Aung Myo Myint
·

10 min read

Introduction to Artifact

Modern software development တွင် Continuous Integration (CI) နှင့် Continuous Delivery (CD) practices များသည် developer များအနေဖြင့် frequently and safely မကြာခဏနှင့် ဘေးကင်းစွာ main codebase ထဲသို့ အပြောင်းအလဲများကို ပေါင်းထည့်နိုင်စေရန် ကူညီပေးပါသည်။ ဒီလိုလုပ်ခြင်းက software development process ကို စည်းစနစ်တကျ quickly and reliably ဖြစ်စွာ ဆောင်ရွက်နိုင်စေသည်။

GitLab CI/CD pipeline တွင် အရေးကြီးသောအချက်တစ်ခုမှာ artifacts ဆိုသော အကြောင်းအရာဖြစ်ပြီး၊ pipeline ၏ various stages အမျိုးမျိုးတွင် files များကို preservation and transfer ပြုလုပ်နိုင်ခြင်း ဖြစ်သည်။ GitLab CI/CD တွင် artifacts များကို ထိရောက်စွာအသုံးပြုနည်းကို နားလည်ခြင်းသည် deployment process ၏ reliability, traceability, and robustness တို့ကို improve ဖြစ်စေပါသည်။

What Is an Artifact?

Artifact သည် pipeline process အတွင်း ထုတ်ပေးသည့် output တစ်ခုဖြစ်သည်။ ၎င်းတို့သည် application မှထွက်ရှိထားသော output result file တစ်ခု သို့မဟုတ် application တစ်ခုတည်ဆောက်ရန်အတွက် လိုအပ်သည့် အခြားအရာများ ဖြစ်နိုင်သည်။

Artifacts can include:

  • Compiled binaries or application builds.

  • Test result logs or code coverage reports.

  • Configuration files or scripts needed for deployment.

  • Any other items or assets generated by a pipeline stage that are necessary for downstream stages.

Artifacts များကို pipeline configuration file (.gitlab-ci.yml) တွင် ကြေငြာပြီး အလုပ်တစ်ခုမှ နောက်တစ်ခုသို့ ရလဒ်များကို ပေးပို့ရန်အတွက် အသုံးပြုပြီး အဆင့်တိုင်းတွင် အောင်မြင်စွာ ပြီးမြောက်ရန် လိုအပ်သောဖိုင်များရှိကြောင်း သေချာစေရန် အသုံးပြုပါသည်။

Why Are Artifacts Important In CI/CD?

Artifacts များသည် CI/CD pipeline တွင် several reasons များအတွင် significant role တစ်ခု အဖြစ်ပါဝင်သည်။

  • Artifacts များသည် project တစ်ခု၏အခြေအနေကို အချိန်နှင့်တစ်ပြေးညီ represent လုပ်သည်။

  • Artifact တွေကို pipeline ရဲ့ အခြားအဆင့်တွေမှာ သိမ်းဆည်းပြီး မျှဝေနိုင်ပါတယ်။ ဒါကတော့ build, test, deployment အဆင့်တွေမှာ အလွယ်တကူ အသုံးပြုနိုင်ဖို့ အထောက်အကူပြုပါတယ်။

  • Artifact တွေက release တစ်ခုမှာ ပြဿနာတက်လာတဲ့အခါ ပြီးခဲ့တဲ့ version ကို ပြန်သွားဖို့ အတွက် အသုံးပြုနိုင်ပါတယ်။ ဒီလိုနဲ့ previous version ကို အလွယ်တကူ ပြန်လည်ထိန်းသိမ်းနိုင်ပါတယ်။

How Artifacts Work in Pipeline?

အထက်ဖော်ပြပါပုံကို အခြေခံ၍ pipeline process ကြည့်ကျရအောင် …

  • Pipeline ကို triggered ပြုလုပ်ခြင်း - User သည် CI/CD application အတွင်း pipeline file (.gitlab-ci.yml, Jenkinsfile, စသည်တို့) ကို အသုံးပြုပြီး pipeline ကို စတင်သည်။ User သည် jobs များကို သတ်မှတ်ပြီးလျှင် pipeline သည် သတ်မှတ်ထားသော rule များအတိုင်း တစ်ခုချင်းစီကို အဆင့်လိုက်လုပ်ဆောင်သည်။ ဤကိစ္စတွင် user သည် job တစ်ခုပြီးစီးသောအခါ artifact များကို generate ပြုလုပ်ရန် rule ကိုလည်း ထည့်သွင်းထားသည်။

  • Pipeline Process အတွင်း Job များကို run ခြင်း - Pipeline file တွင် output ကို artifacts အဖြစ် သိမ်းဆည်းရန် rule ပါဝင်ပါက job တစ်ခုပြီးစီးသောအခါ artifact တစ်ခုကို generate ပြုလုပ်သည်။

  • Deployment Process - Pipeline process များအားလုံးပြီးစီးပြီးသည့်နောက် deployment process ကို စတင်သည်။

Conclusion: Artifacts များသည် CI/CD pipeline ၏ အရေးကြီးသော အစိတ်အပိုင်းဖြစ်ပြီး ၎င်းတို့ကို management ပြုလုပ်ခြင်းက software delivery ၏ speed, safety and reliability ရှိမှုတို့အ‌ပေါ် အရေးပါသော သက်ရောက်မှု significant impact တစ်ခုဖြစ်သည်။

Summary of Artifact Workflow in a Pipeline

Creation: Artifacts များကို pipeline process အတွင်း job တစ်ခုပြီးတိုင်း create ပြုလုပ်သည်။

Storage: ဤ artifacts များကို နောက်ထပ် jobs များ သို့မဟုတ် stages တွေတွင် အသုံးပြုနိုင်ရန် repository(JFrog, nexus repository manager) or storage system (s3) စသည်တို့တွင် သိမ်းဆည်းနိုင်သည်။

Usage: Artifacts များကို pipeline ၏ နောက်ဆုံး deployment stage တွင် deploy ပြုလုပ်ရာတွင် အသုံးပြုသည်။

Sharing: Artifacts များကို pipeline ၏ အခြား stages များနှင့် အခြား pipelines များတွင်လည်း share နိုင်သည်။

Preservation: Artifacts များကို သိမ်းဆည်းထားခြင်းဖြင့် build နှင့် deployments များ၏ history ကို ထိန်းသိမ်းထားနိုင်ပြီး rollback လုပ်ရန်လိုအပ်ပါက ပြန်သုံးနိုင်သည်။

Benefits of Using Artifacts

  • Consistency: Application ၏ same version ကို pipeline တစ်လျှောက်လုံး အသုံးပြုနိုင်စေသည်။ CI/CD pipeline မှာ အများအားဖြင့် စွမ်းဆောင်ရည်များကို တိကျစွာ ထုတ်ယူရန် version control အရေးကြီးပါတယ်။ အကယ်၍ application ၏ version မတူကွဲပြားသော အစိတ်အပိုင်းများကို အသုံးပြုရင်၊ အဆင့်တိုင်းတွင် output မတူညီနိုင်ပြီး အမှားတွေ ဖြစ်နိုင်ပါတယ်။ သို့သော် version တူတူထားခြင်းဖြင့် အရင်ဆုံးအဆင့်မှ နောက်ဆုံးအဆင့်အထိ တူညီသော result ရရှိမည်ဖြစ်ပြီး၊ ယုံကြည်စိတ်ချစွာ အလုပ်များကို ဆက်လက်လုပ်ဆောင်နိုင်သည်။

  • Traceability: Stage တစ်ခုချင်းစီရှိ artifacts များကို tracking ပြုလုပ်နိုင်ပြီး ပြဿနာများကို ဖော်ထုတ်ခြင်းနှင့် ပြန်လည်သုံးသပ်ခြင်းကို ထိရောက်စွာလုပ်ဆောင်နိုင်စေပါသည်။ ဥပမာ - Artifacts များကို CI/CD pipeline ၏ အဆင့်တစ်ခုချင်းစီတွင် သေချာစွာ သိမ်းဆည်းထားခြင်းဖြင့် အစဉ်အဆင့်အသီးသီးတွင် ပြဿနာများကို တိကျစွာ ခွဲခြားစစ်ဆေးနိုင်သည်။ ဥပမာ - စနစ်တစ်ခုတွင် build, test, deploy စသည့် အဆင့်များ ရှိပါက၊ ယင်းတစ်ခုချင်းစီတွင် ရလဒ်များကို artifact အဖြစ် သိမ်းဆည်းထားနိုင်သည်။ အဆိုပါ artifact များကို ပြန်လည်စစ်ဆေးခြင်းဖြင့် အထူးသဖြင့် ပြဿနာများတည်ရှိရာ အဆင့်ကို အလွယ်တကူ ရှာဖွေနိုင်ပြီး ပြန်ပြင်ဆင်နိုင်ပါသည်။

  • Rollback: လက်ရှိ version တွင် ပြဿနာတစ်ခု ပေါ်ပေါက်ပါက၊ ၎င်းသည် previous version သို့ ပြန်လည်ပြောင်းနိုင်သည်။ ဥပမာ - CI/CD pipeline တွင် အသုံးပြုသည့် artifacts များကို စနစ်တကျ သိမ်းဆည်းထားခြင်းကြောင့်, version တစ်ခုစီ၏ အခြေအနေကို သိမ်းဆည်းထားနိုင်သည်။ ဥပမာ - Software ၏ နောက်ဆုံး version တွင် bug (ပြဿနာ) တစ်ခုရှိသည့်အခါ, အရင်က အဆင်ပြေသော version ကို ပြန်လည်သုံးနိုင်ပါတယ်။ ယင်းနည်းလမ်းဖြင့် ပြဿနာမရှိသော ယခင် version သို့ revert (ပြန်သွား) ပြီး၊ အမြန်ဆုံး ပိုမိုယုံကြည်စိတ်ချစွာ ဖြေရှင်းနိုင်စေပါသည်။

  • Efficiency: Artifacts များကို အခြား stages (အဆင့်) များတွင် ထပ်မံအသုံးပြုနိုင်သဖြင့် မလိုအပ်ဘဲ jobs များကို ထပ်လည်ရတဲ့အခြေအနေကို လျှော့ချနိုင်ပါသည်။ ဥပမာ - ပထမ job တွင် compile လုပ်ပြီးသော binary file တစ်ခုကို ရရှိခဲ့ပါက၊ နောက်အဆင့်များတွင် ထပ်ပြီး compile လုပ်ရန် မလိုတော့ပဲ ရှိပြီးသား artifact file ကို အသုံးပြုနိုင်သည်။ ၎င်းကြောင့် အချိန်နှင့် စွမ်းအင်များကို သိသိသာသာသက်သာစေပြီး, whole pipeline ၏ လုပ်ဆောင်ရည်ကို တိုးတက်စေသည်။

Artifacts များကို စနစ်တကျ စီမံခန့်ခွဲခြင်းဖြင့် CI/CD pipeline များသည် artifacts များကို ထိရောက်စွာ စီမံအုပ်ချုပ်နိုင်ပြီး၊ software development နှင့် deployment အစီအစဉ်များကို ပိုမိုတိုးတက်ကောင်းမွန်စေပါသည်။

Running A Simple GitLab CI/CD pipeline

django.nV သည် nVisium မှ provided vulnerabilities Django application ဖြစ်ပါသည်။ ဤ lab ကို စမ်းသပ်ရန်အတွက် repo ကို https://gitlab.com/AungLae/django-nv-aft.git တွင် ရယူနိုင်ပါသည်။

ကျွန်ုပ်တို့သည် ရှိပြီးသား.gitlab-ci.yml ဖိုင်ရှိ contents များကို အောက်ပါ new contents တို့ဖြင့် အစားထိုးပြီး CI/CD pipeline တစ်ခုကို update ပြုလုပ်ရန် လိုအပ်ပါသည်။

Before,

# YAML configuration for CI/CD pipeline

# Dictionary of stages in the pipeline
stages:         # Dictionary
 - build        # this is build stage
 - test         # this is test stage
 - integration  # this is an integration stage
 - prod         # this is prod/production stage

job1:
  stage: build  # this job belongs to the build stage.
  script:
    - echo "This is a build step."  # We are running an echo command, but it can be any command.

job2:
  stage: test
  script:
    - echo "This is a test step."

job3:          
  stage: integration  # integration stage
  script:
    - echo "This is an integration step."

job4:
  stage: prod
  script:
    - echo "This is a deploy step."

After,

# YAML configuration for CI/CD pipeline

# Dictionary of stages in the pipeline
stages:         # Dictionary
 - build        # this is build stage
 - test         # this is test stage
 - integration  # this is an integration stage
 - prod         # this is prod/production stage

job1:
  stage: build  # this job belongs to the build stage.
  script:
    - echo "This is a build step."  # We are running an echo command, but it can be any command.

job2:
  stage: test
  script:
    - echo "This is a test step."
    - exit 1          # Non zero exit code, fails a job.

job3:          
  stage: integration  # integration stage
  script:
    - echo "This is an integration step."

job4:
  stage: prod
  script:
    - echo "This is a deploy step."

Save changes to the file using the Commit changes button.

Verify the Pipeline Run Status Step by Step.

  1. Visit the pipeline's dashboard from Build.

  1. Identify and click on the appropriate pipeline run to view its details.

  1. Review the status of each stage or job within the pipeline.

  1. Click on the specific job name to see the details failed output and logs.

Saving Job Result As Artifact In GitLab

GitLab မှာ artifacts ဆိုတာ CI/CD pipeline တွေကနေ ထွက်လာတဲ့ output files တွေကို သိမ်းထားတဲ့နေရာ ဖြစ်ပါတယ်။ ဥပမာ - test results တွေ၊ build files တွေ၊ scan reports တွေကို artifacts အနေနဲ့ သိမ်းထားနိုင်ပါတယ်။ အဓိက အသုံးဝင်တဲ့ အချက်တွေကတော့

  • အခြား job တွေက ယခင် job ရဲ့ artifacts တွေကို ပြန်သုံးနိုင်တယ်

  • Pipeline ပြီးတဲ့အထိ artifacts တွေကို သိမ်းထားပေးတယ်

  • Web UI ကနေ download လုပ်နိုင်တယ်

  • Expire time သတ်မှတ်နိုင်တယ် (သိမ်းထားမယ့် အချိန်)

Example Configuration

someScan:
  script: 
    - ./security-tool.sh    # <-- this example script may generate a file as an output
  artifacts:                    # <--- To save results, we use artifacts tag
    paths:                      # <--- We then give the path/paths of the scan result files we want to store for further processing
    - vulnerabilities.json                  #<--- The filename
    when: always
    expire_in: 1 week       # <--- To save disk space, we want to store only for 1 week

Steps to Implement Artifacts

  1. Specify the output file’s path under the artifacts tag.

  2. Set the expiration to manage disk space.

Simple Pipeline Example

For simplicity, we will echo a JSON string into a file instead of running a security tool. Here’s the complete pipeline configuration:

# YAML configuration for CI/CD pipeline

# Dictionary of stages in the pipeline
stages:   # Dictionary
 - build   # this is build stage
 - test    # this is test stage
 - integration # this is an integration stage
 - prod       # this is prod/production stage

build:       # this is job named build, it can be anything, job1, job2, etc.,
  stage: build    # this job belongs to the build stage. Here both job name and stage name is the same i.e., build
  script:
    - echo "This is a build step"  # We are running an echo command, but it can be any command.
    - echo "{\"vulnerability\":\"SQL Injection\"}" > vulnerabilities.json
  artifacts:      # notice a new tag artifacts
    paths: [vulnerabilities.json]   # this is the path to the vulnerabilities.json file
    when: always
    expire_in: 1 week       # <--- To save disk space, we want to store only for 1 week

test:
  stage: test
  script:
    - echo "This is a test step."
    - exit 1         # Non zero exit code, fails a job.
  allow_failure: true   #<--- allow the build to fail but don't mark it as such

integration:        # integration job under stage integration.
  stage: integration
  script:
    - echo "This is an integration step."

prod:
  stage: prod
  script:
    - echo "This is a deploy step."

Run the pipeline by clicking the Commit changes button.
Based on above script we will see the following script in build job.

build:       # this is job named build, it can be anything, job1, job2, etc.,
  stage: build    # this job belongs to the build stage. Here both job name and stage name is the same i.e., build
  script:
    - echo "This is a build step"  # We are running an echo command, but it can be any command.
    - echo "{\"vulnerability\":\"SQL Injection\"}" > vulnerabilities.json
  artifacts:      # notice a new tag artifacts
    paths: [vulnerabilities.json]   # this is the path to the vulnerabilities.json file
    when: always
    expire_in: 1 week       # <--- To save disk space, we want to store only for 1 week

You can see the results of the pipeline by visiting:

Once the job succeeds, you can see the artifact displayed at the end of the job report.

Artifact Location

You will find and download the vulnerabilities.json file under the artifacts section on your right-hand side.

Producing Artifact From Docker Output

Pipeline configuration ထဲတွင် docker command တစ်ခု၏ output ကနေ artifact ကို ဘယ်လိုထုတ်ယူလဲဆိုတာ ကြည့်ကျရအောင် …

# YAML configuration for CI/CD pipeline

# Dictionary of stages in the pipeline
stages:
  - build       # build stage
  - test        # test stage
  - integration # integration stage
  - prod        # production stage

build:                   # Job named "build"
  stage: build           # This job belongs to the "build" stage
  script:
    - echo "This is a build step."       # Example build command
    - echo "{\"vulnerability\":\"SQL Injection\"}" > vulnerabilities.json
  artifacts:             # Artifacts to store the output
    paths: 
      - vulnerabilities.json
    when: always
    expire_in: 1 week    # Retain artifacts for one week

test:
  stage: test
  script:
    - echo "This is a test step."
    # Using a workaround for the docker command. Ensure Docker is available if needed.
    - |
      if command -v docker >/dev/null 2>&1; then
        docker run -i -v $(pwd):/app alpine sh -c "echo '{\"vulnerability\":\"XSS Injection\"}' > /app/vulnerabilities.json"
      else
        echo "{\"error\":\"Docker not available\"}" > vulnerabilities.json
      fi
  artifacts:
    paths:
      - vulnerabilities.json
    when: always
  allow_failure: true    # Allow this job to fail without marking the pipeline as failed

integration:
  stage: integration
  script:
    - echo "This is an integration step."    # Placeholder for integration tasks

prod:
  stage: prod
  script:
    - echo "This is a deploy step."          # Placeholder for deployment tasks

The above script defines an artifacts tag to generate an artifact from the script running inside Docker.

Click on the test job to monitor the process until it succeeds.

To check the output file from Artifact location. Click to Browse

Click to “vulnerabilities.json” and then you will see “Docker not available”

So, how to fix this issue and to change this configuration.

Before,

After,

# YAML configuration for CI/CD pipeline

# Dictionary of stages in the pipeline
stages:
  - build       # build stage
  - test        # test stage
  - integration # integration stage
  - prod        # production stage

build:                   # Job named "build"
  stage: build           # This job belongs to the "build" stage
  script:
    - echo "This is a build step."       # Example build command
    - echo "{\"vulnerability\":\"SQL Injection\"}" > vulnerabilities.json
  artifacts:             # Artifacts to store the output
    paths: 
      - vulnerabilities.json
    when: always
    expire_in: 1 week    # Retain artifacts for one week

test:
  stage: test
  image: docker:latest          # Use Docker-enabled image
  services:
    - docker:dind               # Enable Docker-in-Docker service
  variables:
    DOCKER_TLS_CERTDIR: ""      # Required for Docker-in-Docker on newer GitLab versions
  script:
    - echo "This is a test step."
    - |
      if command -v docker >/dev/null 2>&1; then
        docker run -i -v $(pwd):/app alpine sh -c "echo '{\"vulnerability\":\"XSS Injection\"}' > /app/vulnerabilities.json"
      else
        echo "{\"error\":\"Docker not available\"}" > vulnerabilities.json
      fi
  artifacts:
    paths:
      - vulnerabilities.json
    when: always
  allow_failure: true    # Allow this job to fail without marking the pipeline as failed

integration:
  stage: integration
  script:
    - echo "This is an integration step."    # Placeholder for integration tasks

prod:
  stage: prod
  script:
    - echo "This is a deploy step."          # Placeholder for deployment tasks

Conclusion

GitLab မှာ job results တွေကို artifacts အနေနဲ့ storing ပြုလုပ်တဲ့ process တွင် artifact ဆိုတဲ့ tag ကို security scan script တစ်ခုအားဖြင့် files တွေကို generated ပြုလုပ်ခဲ့ပြီး script output တွေကို နောက်နောင်တွင် ပြန်လည်အသုံးပြုဖို့ save ပြုလုပ်ရာတွင် အသုံးပြုပါတယ်။ ဒီ output (သို့) artifact ကို လွယ်ကူစွာ ပြန်လည်ရယူဖို့အတွက် predetermined paths တွေမှာ သတ်မှတ်ပြီး သိမ်းဆည်းထားပါတယ်။

build လို့ခေါ်တဲ့ sample job တစ်ခုကို demonstrated ပြသထားခဲ့ပြီး၊ အဲဒီမှာ echo command ကို အသုံးပြုပြီး "vulnerabilities.json" လို့ခေါ်တဲ့ ဖိုင်တစ်ခုကို generate ပြုလုပ်ထားပါတယ်။

'artifacts' ဆိုတဲ့ tag ကို သတ်မှတ်လိုက်တိုင်း job တစ်ခုချင်းစီက artifacts တွေကို ထုတ်လုပ်ပါတယ်။ ဒီ artifacts တွေဟာ stage တစ်ခုချင်းစီအကြောင်း တန်ဖိုးရှိတဲ့ အချက်အလက်တွေကို ပေးနိုင်ပြီး ထပ်မံ လေ့လာဆန်းစစ်ဖို့အတွက် download လုပ်နိုင်ပါတယ်။ ဒီလုပ်ငန်းစဉ်ဟာ CI/CD pipeline ရဲ့ quality ကို maintaining and debugging လုပ်ဖို့အတွက် အရေးပါတဲ့ အထောက်အကူ ပြုပါတယ်။

GitLab