CI/CD Advance
gitlab duo chat
질문이 있으면 duo chat을 이용하자. 메뉴가 찾기 어렵다. 서비스에 따라서 없을수도 있다.

start pipeline
.gitlab-ci.yml
생성 (gitlab-ci.yaml
은 동작하지않음)
stage
job
stage가 생성이 된다. 그리고 job이 생성이 된다.
stage는 tagging system과 비슷하다. 모든것은 Job으로 움직이지만 stage는 job을 그룹화 시키는 역할을 한다.
image: docker:latest
services:
- docker:dind
variables:
CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_COMMIT_SHA
DOCKER_DRIVER: overlay2
RUNNER_GENERATE_ARTIFACTS_METADATA: 'true'
stages:
- mybuild
- mytest
build:
stage: mybuild
variables:
IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
before_script:
- docker info
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- cd app
- docker build -t $IMAGE .
after_script:
- docker push $IMAGE
test:
stage: mytest
image: alpine:latest
script:
- echo hello
script, before_script, and after_script
before_script: script전에 실행된다. 그리고 script와 같은 shell에서 실행된다.
script : runner에 의해서 실행된다. exitcode는 여기에서 리턴된다.
after_script : Runs in a separate shell after the before_script / script statements. (다른 쉘에서 실행된다. ) , exitcode 에 대해서는 상관하지 않는다.
test에 코드 추가
test:
stage: mytest
image: alpine:latest
script:
- echo hello
after_script:
- echo "Our race track has been tested!"
실행 순위
stage 순서대로 실행된다.
Jobs in the next stage will start after all jobs in the previous stage have completed successfully
다음 단계의 작업은 이전 단계의 모든 작업이 성공적으로 완료된 후 시작됩니다.

GitLab Runners
type
SSH
Shell
Virtual Box
Parallels
Docker
Docker Autoscaler (Beta)
Docker Machine
Kubernetes
Custom
tag
tag를 이용해서 runner를 선택할 수 있다.
job:
tags:
- myrunner
실행 순서 수정
need를 사용하여 특정 작업 다음에 실행을 할수 있다.
경우에 따라서 stage를 동시에 실행하고 싶을수 있다.
test:
stage: mytest
image: alpine:latest
script:
- echo hello
after_script:
- echo "Our race track has been tested!"
needs: []
super_fast_test:
stage: test
script:
- echo "If youre not first youre last"
- return 0
needs: []
두개의 잡이 다른잡을 기다리지 않고 동시에 실행된다.

build가 안끝나도 test가 실행된다. job dependencies가 생겼고 dependency가 없는것을 볼수 잇다.
Directed Acyclic Graph
stage추가하고 다음 코드를 추가해보자.
stages:
- race
build_car_a:
stage: mybuild
script:
- echo "build_car_a"
build_car_b:
stage: mybuild
script:
- echo "build_car_b"
build_car_c:
stage: mybuild
script:
- echo "build_car_c"
build_car_d:
stage: mybuild
script:
- echo "build_car_d"
build_car_e:
stage: mybuild
script:
- echo "build_car_e"
build_car_f:
stage: mybuild
script:
- echo "build_car_f"
test_car_a:
stage: mytest
needs: [build_car_a]
script:
- echo "test_car_a"
test_car_b:
stage: mytest
needs: [build_car_b]
script:
- echo "test_car_b"
test_car_c:
stage: mytest
needs: [build_car_c]
script:
- echo "test_car_c"
test_car_d:
stage: mytest
needs: [build_car_d]
script:
- echo "test_car_d"
test_car_e:
stage: mytest
needs: [build_car_e]
script:
- echo "test_car_e"
test_car_f:
stage: mytest
needs: [build_car_f]
script:
- echo "test_car_f"
race_car_a:
stage: race
needs: [test_car_a]
script:
- echo "race_car_a"
race_car_b:
stage: race
needs: [test_car_b]
script:
- echo "race_car_b"
race_car_c:
stage: race
needs: [test_car_c]
script:
- echo "race_car_c"
race_car_d:
stage: race
needs: [test_car_d]
script:
- echo "race_car_d"
race_car_e:
stage: race
needs: [test_car_e]
script:
- echo "race_car_e"
race_car_f:
stage: race
needs: [test_car_f]
script:
- echo "race_car_f"


여기에서 보면 볼수 잇다.
원복하자.
Stageless Pipelines
버전에 따라서 다르지만 기존에는 need는 다른 stage에 job에 적용할수 있었습니다.
이제는 같은 stage에서도 need가 적용됨. Allows “needs” keyword to be used in the same stage
파이프라인을 좀더 효과적으로 만들수 있습니다.
실행순서를 좀더 명확하게 정할수 있습니다.
Available in (All tiers; 14.2+)
Caching Basics
To cache, a GitLab Runner will take the content you cached and store it in GCP Cloud Storage
Cache Execution Order
Pipeline starts.
job A runs.
before_script is executed.
script is executed.
after_script is executed.
cache runs and the vendor/ directory is zipped into cache.zip. This file is then saved in the directory based on the runner’s setting and the cache: key.
job B runs.
The cache is extracted (if found).
before_script is executed.
script is executed.
Pipeline finishes.
why cache?
작업 간에 다운로드한 콘텐츠 공유: 코드의 여러 브랜치에서 수행할 수도 있습니다. 코드 종속성 저장(다음에 다운로드할 때까지 기다릴 필요 없음) 파이프라인 속도 향상
job A:
stage: mybuild
script:
- mkdir vendor/
- echo "Hello World" > vendor/hello.txt
cache:
key: build-cache
paths:
- vendor/
after_script:
- echo "world"
job B:
stage: mytest
script:
- cat vendor/hello.txt
cache:
key: build-cache
paths:
- vendor/

hello.txt를 다음작업이 받아서 처리할수 있다.
hello world 가 찍히는걸 볼수 있다. 파일을 가져왔다는 뜻이다.
좀더 의미잇는 샘플을 해보자. ruby를 빌드를 먼저해서 그걸 캐시해두고 다음작업에서 가져와서 사용할수 있다.
좀더 의미잇는 샘플을 해보자. ruby를 빌드를 먼저해서 그걸 캐시해두고 다음작업에서 가져와서 사용할수 있다.
# Cache modules in between jobs
cache:
- key: cache-$CI_COMMIT_REF_SLUG
fallback_keys:
- cache-$CI_DEFAULT_BRANCH
- cache-default
paths:
- vendor/ruby
- Gemfile.lock
npm도 마찬가지이다. 처음부터 다 설치하지 않고 설치된 파일들을 다운받은후 사용하면 빌드 시간을 줄일수 잇다.
Allowing Job Failure (job 실패를 허용)
We need to find a way to configure the pipeline so that even when the unit test job fails, subsequent jobs still execute.
단위 테스트 작업이 실패하더라도 후속 작업이 계속 실행되도록 파이프라인을 구성하는 방법
allow_failure: true
- failing job is logged in the pipeline as failed, but does not prevent subsequent jobs from executing
allow_failure 를 사용하면된다.
스크립트 exit 1
을 실패를 리턴한다.
stage에 deploy를 추가한다.allow_failure: true
가 없으면 deploy는 실행되지 않는다.
stages:
- deploy
super_fast_test:
stage: mytest
script:
- exit 1
needs: []
allow_failure: true
deploy:
stage: deploy
script:
- echo "Deploying"
needs: [super_fast_test]
allow_failure: true
없는 경우
allow_failure: true
있는 경우
rules
rules을 추가
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
맞는 조건에만 실행이 된다.
When is a Job NOT created in a Pipeline?
When is a Job NOT created in a Pipeline?
A job is not included in a pipeline if:
None of the rules defined for the job evaluate to true
A rule evaluates to true, but has clause of when: never
No rules are defined but a when: never clause is specified
다음과 같은 경우 작업은 파이프라인에 포함되지 않습니다:
작업에 대해 정의된 규칙 중 어느 것도 참으로 평가되지 않습니다.
규칙이 참으로 평가되지만
when: never
절이 있습니다.규칙이 정의되어 있지 않지만
when: never
절이 지정되어 있습니다.
job:
script: echo "Hello, World!"
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
- if: $CI_PIPELINE_SOURCE == "schedule"
when: never
- when: on_success
두개의 경우에는 job이 실행되지 않는다.
when: on_success : 이전 작업이 성공했다고 가정하여 작업을 실행하도록 지시합니다. 이줄에 오면 기존 if는 어느것도 만족하지 않을때 여기까지 오게 된다.
when: manual
수동으로 실행하고 싶으면 when: manual
을 추가하면 된다.
화면에서 실행버튼이 나오므로 그걸 누르면된다.
super_fast_test:
stage: mytest
script:
- exit 1
needs: []
allow_failure: true
deploy:
stage: deploy
script:
- echo "Deploying"
needs: [super_fast_test]
when: manual

If $CI_PIPELINE_SOURCE is set to merge_request_event or schedule, the job is executed
CI_PIPELINE_SOURCE가 merge_request_event 또는 스케줄로 설정된 경우 작업이 실행됩니다.
job:
script: echo "Hello, World!"
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_PIPELINE_SOURCE == "schedule"
when for delaying a job run
If used as when: delayed, start_in is also required.
job:
script: echo "Hello, World!"
rules:
- if: $CI_COMMIT_BRANCH == "master"
when: delayed
start_in: 3 hours
using changes and if
job:
script: docker build -t
rules:
- if: $VAR == "string value"
changes:
- Dockerfile
- docker/scripts/*
when: manual
경로중에 파일이 바귀면 실행되도록 할수 있다.
위 내용은 두개의 경로의 파일이 하나라더 바귀면 실행된다. AND를 실행하려면 아래와 같이 하면된다.
changes:
- Dockerfile AND docker/scripts/*
variables Processing Order
The order of precedence for variables is (from highest to lowest): 변수의 우선 순위는 (높은 것부터 낮은 것) 입니다
CICD pipeline Trigger variables, scheduled pipeline variables, and manual pipeline run variables.
Project-level variables or protected variables.
Group-level variables or protected variables.
Instance-level variables or protected variables.
Inherited environment variables.
YAML-defined job-level variables.
YAML-defined global variables.
Deployment variables.
Predefined environment variables.

Stroing with artifacts
build:
stage: build
script:
- echo hi > test.txt
artifacts:
paths:
- test.txt
expire_in: 1 hour

artifacts을 다운로드할수 있습니다.
template
How to get SAST from GitLab
SAST는 Static Application Security Testing의 약자이다.
include:
- template: Security/SAST.gitlab-ci.yml
sast job: chosen stage does not exist; available stages are .pre, mytest, deploy, .post
add test stage
stages:
- test
Now that we have SAST lets add a few more security templates to our project to confirm that our code is secure
include:
- template: Code-Quality.gitlab-ci.yml

child process
SAST를 활성화하여 파이프라인을 데모한 후 보안 팀에서 더 많은 스캐너로 자체 파이프라인을 실행하고 있으며 이를 파이프라인과 통합하기를 원한다는 사실을 알려줍니다. 이를 위한 가장 좋은 방법은 하위 파이프라인을 설정하는 것이라고 결정합니다.
전체 코드를 업데이트하자.
image: docker:latest
services:
- docker:dind
stages:
- build
- test
build:
stage: build
script:
- echo hello
new stage 추가
stages:
- build
- test
- extra-security
extra-security 추가. trigger를 사용하고 include를 사용한다.
downstream_security:
stage: extra-security
trigger:
include:
- local: security-pipeline/security.gitlab-ci.yml
create folder and file
security-pipeline/security.gitlab-ci.yml
image: docker:latest
include:
- template: Code-Quality.gitlab-ci.yml
- template: Jobs/Dependency-Scanning.gitlab-ci.yml
- template: Jobs/SAST.gitlab-ci.yml
- template: Jobs/Secret-Detection.gitlab-ci.yml
어떤 파이프라인이라도 추가해서 사용할수 있다.

Downstream Pipelines
Two types:
Parent-child
파이프라인이 같은 프로젝트에 존재
부모 파이프라인과 동일한 프로젝트, 참조 및 커밋 SHA에서 실행됩니다.
기본적으로 파이프라인이 실행되는 참조의 전체 상태에 직접적인 영향을 미치지 않습니다(자식 파이프라인을 트리거할 때
strategy:depend
를 사용하지 않는 한).중첩된 레벨 2개로 제한
Multi-project
파이프라인은 여러 프로젝트에 존재합니다.
업스트림(트리거링) 파이프라인은 다운스트림(트리거링) 파이프라인에 대한 제어 권한이 많지 않습니다.
실행 중인 프로젝트의 전체 참조 상태에는 영향을 주지만 트리거 파이프라인의 참조 상태에는 영향을 미치지 않습니다.
독립적이므로 중첩 제한이 없습니다.
Rules & Child Pipelines
Allows you to get creative and make dynamic changes to the current results of your pipelines 창의력을 발휘하여 파이프라인의 현재 결과를 동적으로 변경할 수 있습니다.
Last updated
Was this helpful?