Ubuntu 20.04에서 GitLab 지속적 통합(CI) 파이프라인을 설정하는 방법

모든 개발자는 버전 관리가 소프트웨어 개발 수명 주기에서 얼마나 중요한지 잘 알고 있습니다. 버전 관리를 통해 여러 사람이 하나의 프로젝트에서 동시에 작업할 수 있으며, 각자 자신의 코드 복사본을 유지하면서 이를 팀의 나머지 구성원과 공유할 시기를 선택할 수 있습니다. 이를 위해 개발자는 Git 저장소를 활용하여 버전 관리를 수행합니다. GitLab은 단순한 버전 관리 도구 그 이상인 웹 기반 Git 저장소입니다. 또한 DevOps 도구, 이슈 추적, 지속적 통합 및 배포를 제공합니다.

GitLab은 선택할 수 있는 세 가지 옵션을 제공합니다: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) 및 GitLab SaaS. GitLab CE 및 GitLab EE 은 자체 관리형 솔루션입니다. 즉, GitLab 인스턴스를 직접 다운로드, 설치 및 관리해야 합니다. GitLab SaaS는 GitLab Inc.에서 호스팅하므로 사용하기 위해 아무것도 설치할 걱정을 하지 않아도 됩니다. 단지 GitLab 계정을 생성하고 시작하시면 됩니다.

이 튜토리얼에서는 지속적 통합(Continuous Integration) 파이프라인을 구축하는 방법을 GitLab CI를 통해 보여드리겠습니다. 저장소의 변경 사항을 모니터링하고 자동화된 테스트를 실행하여 새 코드를 검증하기 위해. 먼저 코드를 호스팅할 Git 저장소를 설정하는 것부터 시작합니다. 그런 다음 저장소로의 커밋을 모니터링하는 CI 프로세스를 구성하고 격리된 Docker 컨테이너에서 테스트를 실행하기 위해 CI 러너를 시작합니다.

사전 요구 사항

시작하려면 GitLab 버전 관리 소프트웨어가 실행되는 서버가 필요합니다. GitLab 자체 관리형(self-managed)과 SaaS 모두 자동화된 테스트를 실행할 수 있습니다. 하지만 무료 SaaS 옵션에서는 테스트에 제공되는 시간(분) 및 리소스에 일부 제한이 있습니다. 자체 관리형 옵션을 사용하면 GitLab 인스턴스에 원하는 만큼 리소스를 할당할 수 있으므로 더 자유롭게 사용할 수 있습니다. 다음 가이드를 참조하여 GitLab으로 자체 Git 리포지토리 호스팅하기를 통해 자신만의 GitLab 인스턴스를 설정하는 방법을 알아보세요.

GitLab CI runner로 사용할 서버가 최소 하나 이상 필요합니다. 하지만 원하신다면 더 많은 서버를 가질 수도 있습니다. 자체 관리형 GitLab 인스턴스를 설정한 경우 동일한 서버를 사용할 수 있지만, CI runner를 위해 다른 서버를 설정하는 것을 선호합니다. 다음 튜토리얼인 Ubuntu 서버를 설정하는 방법은 좋은 시작이 될 것입니다.

Docker 컨테이너에서 테스트 환경을 격리하려면 GitLab CI runner 서버에 Docker를 설치해야 합니다. 저희는 Ubuntu에서 Docker를 설치하고 운영하는 방법에 대한 튜토리얼을 제공하고 있으며, 이는 이 요구 사항을 완료하는 데 도움이 될 것입니다.

이제 필요한 모든 것이 준비되었으니 시작해 보겠습니다!

1단계: GitLab 인스턴스에 프로젝트 생성하기

먼저 GitLab에 프로젝트 저장소를 만드는 것부터 시작해 보겠습니다. 이 튜토리얼은 Node.js 애플리케이션을 기반으로 합니다. 프로젝트 파일을 처음부터 만들고 싶지는 않으므로, GitLab에서 제공하는 다른 버전 관리 저장소의 프로젝트를 가져오는 도구를 사용할 것입니다. 가져올 애플리케이션은 간단한 “hello world” 앱이며, Express.js – Node.js 애플리케이션을 위한 미니멀한 웹 프레임워크로 빌드되었습니다. 테스트는 다음을 사용하여 구현합니다: Mocha 및 Chai – 이들은 단위 테스트에 사용되는 JavaScript 프레임워크입니다. Mocha는 비동기 테스트, 테스트 커버리지 보고서를 지원하며 다른 어설션 라이브러리와 함께 사용할 수 있습니다. Chai는 어설션 라이브러리입니다. 어떤 테스트 프레임워크와도 결합할 수 있으며, 이 프로젝트의 경우 Mocha와 Chai를 함께 사용하겠습니다.

이제 프로젝트의 기본 사항을 알았으므로 GitLab 인스턴스(자체 관리형 또는 SaaS)에 로그인하고 상단 탐색 모음에서 ‘플러스’ 아이콘을 클릭한 다음 ‘새 프로젝트’를 선택합니다. 또는 계정 홈 페이지의 맨 위로 스크롤하면 ‘새 프로젝트’ 버튼을 클릭할 수 있습니다:

새 프로젝트 페이지에서 Import project 탭을 클릭합니다:

다음으로, 열린 페이지에서 Repo by URL 버튼을 클릭합니다:

GitHub 가져오기 옵션이 있지만, 개인 액세스 토큰(Personal access token)이 필요하므로 사용하지 않을 것입니다. 우리는 공개 저장소로 작업하므로 개인 액세스 토큰을 설정할 필요가 없으며, URL만으로 가져오는 것이 간단합니다.

그 후, 다음 URL을 복사하여 Git Repository URL 필드에 붙여넣으세요:

다음과 같이 보여야 합니다:

저장소 설정을 다음 상태로 유지합니다: Private 완료되면 Create project 버튼을 클릭합니다. GitHub에서 프로젝트를 가져오는 동안 몇 초간 기다리면 GitLab 저장소에 나타납니다. GitLab은 GitHub 저장소 프로젝트와 동일한 세부 정보로 프로젝트를 가져옵니다.

2단계: .gitlab-ci.yml 파일 분석하기

GitLab CI는 GitLab의 모든 저장소에서 .gitlab-ci.yml 이라는 파일을 검색하여 자동화된 테스트를 실행하는 방법을 파악합니다. 방금 가져온 저장소의 프로젝트 파일 중에서 .gitlab-ci.yml 파일을 볼 수 있습니다. GitLab CI yml 에 대한 자세한 정보는 공식 .gitlab-ci.yml 파일 문서에 대한 키워드 참조.

GitLab 저장소 인터페이스에서 .gitlab-ci.yml 파일을 클릭하여 브라우저 페이지에서 엽니다. 다음과 같이 표시되어야 합니다:

줄의 들여쓰기에 유의하세요. 이 파일은 엄격한 GitLab CI YAML 설정 구문을 따릅니다. 이 구문은 특정 조건에서 지정된 순서대로 수행할 다양한 작업을 정의합니다. 설정 파일이 올바른지 확인하기 위해 GitLab은 유효성 검사를 위한 테스트 유틸리티를 제공합니다. GitLab 인스턴스 내부의 프로젝트 저장소에서 CI lint 인터페이스를 방문하여 .gitlab-ci.yml 파일의 유효성을 검사할 수 있습니다. 왼쪽 탐색 메뉴에서 CI/CD를 클릭한 다음, 나타나는 페이지에서 CI lint 버튼을 클릭하세요:

설정 파일의 지시어는 아래에서 설명합니다.

• 기본 Docker 이미지

설정 파일의 첫 번째 줄은 테스트를 실행하는 데 사용해야 하는 Docker 이미지를 선언합니다. Node.js 애플리케이션을 빌드하고 있으므로 최신 Node.js 이미지를 사용합니다:

• 스테이지

그런 다음, 지속적 통합 테스트가 거쳐가기를 원하는 다양한 스테이지를 정의합니다. 여기에는 두 가지 스테이지가 있습니다:

스테이지 이름을 정의하는 동안, 다음과 같은 이름은 build 또는 test 은(는) 임의로 지정됩니다 – 원하는 이름을 자유롭게 선택할 수 있습니다. 하지만 스테이지 순서가 실행 흐름을 결정하므로 순서를 올바르게 지정해야 합니다. 우리의 경우, build 단계의 작업이 test 단계의 작업보다 먼저 실행됩니다. GitLab 러너는 동일한 단계의 작업을 병렬로 실행하며, 다음 단계의 작업을 시작하기 전에 모든 작업이 완료될 때까지 기다립니다.

• 캐시

작업 실행 사이에 나중에 사용하기 위해 캐시되거나 저장될 파일과 디렉터리를 지정하기 위해 cache 정의가 포함되어 있습니다:

캐싱을 정의하면 실행 간에 변경될 가능성이 낮은 리소스에 의존하는 작업을 실행하는 데 걸리는 시간을 최소화하는 데 도움이 됩니다. 캐시할 node_modules 디렉터리를 지정합니다. 이 디렉터리는 npm이 프로젝트의 종속성을 설치하는 디렉터리입니다.

• 작업

구성에는 두 개의 작업이 있습니다:

• install_dependencies

작업 이름을 지정할 때 어떤 이름이든 자유롭게 선택할 수 있습니다. 하지만 GitLab UI에서 사용되므로 설명적인 이름을 사용하는 것이 좋습니다 – 이는 디버깅할 때 도움이 될 수 있습니다. 웹상의 대부분의 구성에서는 npm install을 테스트 단계의 명령과 결합하여 사용하는 것을 볼 수 있습니다. 이 프로젝트는 매우 작기 때문에 작업이 어떻게 상호 작용하는지 보여주기 위해 이들을 분리했을 뿐입니다. stage 지시어는 이 작업을 build로 지정합니다 – 이 작업은 build stage에서 실행됩니다..

The script 지시어는 이 작업의 실행에서 실행할 명령을 지정합니다. 다음 내에 줄을 추가하여 여러 명령을 지정할 수 있습니다: script 블록. 물론 적절히 들여쓰기를 하고, 스크립트가 실행되어야 하는 순서를 염두에 두어야 합니다.

The artifacts 지시어는 스테이지 간에 저장하고 공유할 파일 또는 디렉터리 경로를 지정합니다. 다시 한번 강조하지만, 다른 파일이 실행하는 데 필요한 것을 갖추도록 하려면 스테이지 순서를 올바르게 지정하는 것이 중요합니다. npm install 명령은 다음 위치에 종속성을 설치합니다: node_modules 디렉터리. 이를 artifacts에 선언함으로써 후속 스테이지에서 실행되는 작업에서 사용할 수 있도록 합니다. 파일을 다운로드하려는 경우 GitLab UI에서도 이 파일들을 사용할 수 있습니다.

• test_with_mocha

이 작업은 test 스테이지에서 실행됩니다. 이 작업은 build 스테이지의 작업이 실행된 후에 실행되므로, build 스테이지에서 선언된 아티팩트(우리 앱의 의존성)를 test 스테이지에서 사용할 수 있습니다. script 블록은 npm 테스트를 실행하는 명령입니다. 먼저 애플리케이션을 시작한 다음 애플리케이션을 대상으로 테스트를 실행합니다. 이 명령들을 실행하면 다음의 package.json 스크립트 블록 섹션에 지정된 명령이 실행됩니다:
이것으로 여러분은 다음의 .gitlab-ci.yml 파일에 대해 기본적인 이해를 하셨을 것입니다. 이것은 단지 정적인 hello world 앱이기 때문에 기본적이라고 말씀드린 것입니다. 다음으로, 새로운 CI 실행을 트리거하는 방법을 알아보겠습니다.

3단계: GitLab CI 실행 트리거하기

기쁘게도 여러분의 저장소에 다음 파일이 있으면 .gitlab-ci.yml 파일, 여기에 푸시하는 새로운 커밋은 새로운 Continuous Integration 실행을 트리거합니다. 자체 관리형 GitLab 인스턴스의 경우, GitLab 러너를 구성하지 않았다면 CI 실행이 “pending”으로 설정됩니다.

GitLab SaaS는 사용자에게 작업을 가져가서 자동으로 실행할 수 있는 공유 러너를 제공합니다. 이는 공유 러너가 유휴 상태이고 할당량을 초과하지 않은 경우에만 가능합니다. GitLab SaaS에서는 다음 경로에서 저장소의 공유 러너 사용 여부를 선택할 수 있습니다: 프로젝트의 Settings > CI / CD 페이지가 아래 스크린샷과 같이 표시됩니다. 이 페이지에서는 다음 단계에서 자세히 알아볼 GitLab runner 설치 지침에 대한 정보도 확인할 수 있습니다:

이제 CI 실행을 트리거하기 위해 작은 변경을 수행해 보겠습니다. 다시 귀하의 node_pipeline GitLab 프로젝트 저장소로 이동합니다:

위에서 강조 표시된 README.md 파일을 클릭하여 확인합니다:

브라우저에서 편집할 수 있도록 파일을 열려면 ‘Edit’ 버튼을 클릭하고 텍스트를 추가합니다:

텍스트를 추가했으면 아래로 스크롤하여 Commit changes 버튼을 눌러 변경 사항을 저장합니다. 커밋 메시지는 원하는 대로 수정할 수 있습니다. 파이프라인이 실행될 때 GitLab UI에 제목으로 표시됩니다. 저희는 이를 Update README.md 로 두었습니다. 설명이 아주 잘 되어 있기 때문입니다:

변경 사항을 커밋한 후 메인 프로젝트 페이지로 돌아갑니다. 가장 최근 커밋에 작은 일시정지 아이콘이 표시된 것을 볼 수 있습니다. 아이콘 위에 마우스를 올리면 다음과 같이 표시됩니다: ‘Pipeline:pending’:

이는 CI 실행이 트리거되었음을 의미합니다. 하지만 테스트는 아직 실행되지 않았습니다. 왼쪽 탐색 메뉴에서 CI/CD,를 클릭한 다음 Pipelines를 선택합니다. 이 페이지를 열면 파이프라인에 대한 더 자세한 정보를 보여주는 페이지가 열립니다. CI가 대기 중이고 멈춤 상태로 표시된 것을 볼 수 있습니다:

실행에 대한 자세한 정보를 보려면 대기 중 상태를 클릭하세요. 아래와 같은 화면이 나타나며, 실행의 다양한 단계와 각 단계에 연결된 개별 작업이 표시됩니다:

개별 작업을 클릭하여 지연 원인과 같은 세부 정보를 확인할 수도 있습니다. 실행이 실패한 경우, 여기에서 작업이 실패한 원인을 확인할 수 있습니다:

이 메시지는 이 작업을 실행할 수 있는 활성 러너를 구성하지 않았기 때문에 작업이 중단되었음을 나타냅니다. 다음 단계에서 이 작업을 수행할 것입니다. 러너를 사용할 수 있게 되면 작업이 자동으로 실행되기 시작합니다. 작업이 실행되면 이 인터페이스에서 출력뿐만 아니라 작업이 실행되는 동안 생성된 다른 다운로드 가능한 아티팩트도 볼 수 있습니다.

4단계: GitLab CI 러너 서비스 설정하기

이제 다음에서 선언한 두 번째 서버를 사용할 차례입니다: 준비 사항 섹션 이 튜토리얼의. 이 서버에 GitLab 러너 서비스를 설치하고 설정할 것입니다. GitLab의 서로 다른 프로젝트를 위해 여러 러너 인스턴스를 실행하도록 서비스를 배포할 수 있습니다.

자체 관리형 GitLab 인스턴스를 호스팅하는 동일한 서버에 러너를 배포할 수도 있습니다. 하지만 인스턴스가 리소스 제한을 받지 않도록 하려면 별도의 CI 러너 인스턴스를 설정하는 것이 좋습니다. 어떤 구성을 선택하든, Docker가 설치되어 있어야 합니다 테스트 환경을 격리하기 위해.

GitLab CI 러너를 설치하는 과정은 다음을 위한 과정과 유사합니다. GitLab 자체 관리형 인스턴스 설치. 다음 명령을 사용하여 공식 GitLab 리포지토리를 apt 소스에 추가하는 스크립트를 다운로드하는 것부터 시작합니다:

프롬프트가 표시되면 root 비밀번호를 입력합니다. 다음으로, 최신 GitLab CI 러너를 설치하는 명령을 실행할 수 있습니다:

위 명령은 프로젝트에서 사용할 준비가 된 러너 서비스를 설치하고 등록합니다.

5단계: 등록 토큰 획득 및 GitLab Runner 연결

GitLab CI 러너가 작업을 수락하도록 설정하려면 GitLab 러너 토큰이 필요합니다. 이 토큰은 러너가 GitLab 서버 인스턴스에 인증하는 데 필요합니다. 러너를 사용하는 방법에 따라 두 가지 유형의 토큰이 있습니다: 프로젝트 전용 및 공유 러너.

프로젝트 전용 러너는 러너에 대한 고유한 요구 사항이 있는 경우에 적용됩니다. 예를 들어, 귀하의 gitlab-ci.yml 고유한 토큰을 사용하는 경우, 배포 환경에 올바르게 인증하기 위해 특정 러너가 권장될 수 있습니다. 또 다른 고려 사항은 지속적 통합 단계에 리소스 집약적인 프로세스가 있는지 여부입니다. 그렇다면 프로젝트 전용 러너를 사용하는 것이 이상적입니다. 프로젝트 전용 러너는 다른 프로젝트의 작업을 수락하지 않습니다.

공유 러너는 범용이며 여러 프로젝트에서 사용할 수 있습니다. GitLab Inc에 호스팅된 GitLab SaaS 인스턴스에는 일부 공유 러너가 있으며, 이들은 다음에서 설명한 대로 파이프라인을 자동으로 가져옵니다: 3단계. 러너는 각 프로젝트에 대해 현재 실행 중인 작업 수를 고려하는 알고리즘을 기반으로 구성에서 작업을 가져옵니다. 공유 러너는 특정 러너보다 더 유연합니다. GitLab 인스턴스의 관리자 계정에서 구성할 수 있습니다. 두 러너의 토큰을 얻는 방법을 알아보겠습니다.

• 프로젝트 전용 러너 등록하기

프로젝트 전용 러너를 등록하려면 GitLab 인스턴스 또는 GitLab SaaS 계정에서 프로젝트를 엽니다. 왼쪽 탐색 메뉴에서 설정 항목을 클릭하고 CI/CD 옵션을 선택합니다:

그 후, 아래로 스크롤하여 러너 섹션에서 버튼을 클릭하여 섹션을 확장합니다:

왼쪽에는 프로젝트 전용 러너를 등록하는 방법이 설명되어 있습니다. 이것은 GitLab SaaS 인스턴스의 화면입니다. Kubernetes를 사용하여 자동 러너를 구성할 수도 있지만, 이 튜토리얼에서는 수동 러너를 사용합니다:

다음으로, 이 프로젝트의 토큰이 제공되는 섹션에 집중해야 합니다. 자체 관리형 GitLab 인스턴스의 경우, URL에 GitLab 인스턴스가 실행 중인 서버의 도메인이 표시됩니다:

이 프로젝트에 대한 공유 러너를 비활성화하려면 다음 항목 아래의 오른쪽 섹션에 있는 스위치를 전환하면 됩니다: 공유 러너(Shared Runners). 그런 다음 나중에 사용할 수 있도록 표시된 등록 토큰을 메모장에 복사해 둡니다.

• 공유 러너 등록하기

공유 러너를 등록하려면 자체 관리형 GitLab 인스턴스에 관리자로 로그인해야 합니다. 관리자 패널에 액세스하려면 상단 탐색 메뉴에서 렌치/스패너 모양 아이콘을 클릭합니다:

In the 관리자 패널에서, Runners (왼쪽 메뉴의 Overview 섹션)를 클릭합니다. 그러면 공유 러너(Shared Runners) 설정 안내가 표시된 페이지가 열립니다:

우측의 공유 Runner 수동 설정 아래에 표시된 등록 토큰을 복사합니다. 다음 단계에서 이 토큰을 사용하여 러너를 등록합니다.

• GitLab CI Runner와 GitLab 인스턴스 연결하기

이 단계에서는 GitLab 인스턴스를 CI 러너와 연결합니다. 다음에서 GitLab 러너 서비스를 설치한 서버에 다시 로그인합니다: 4단계. 러너 등록 프로세스를 시작하려면 터미널에 다음 명령어를 입력하십시오:

이 명령어를 실행하면 일련의 질문이 표시됩니다:

• GitLab 인스턴스 URL을 입력하세요 (예: https://gitlab.com/):

GitLab 인스턴스의 도메인 이름을 제공할 때 https://를 사용하여 SSL을 지정하세요.

• 등록 토큰을 입력하세요:

등록 토큰을 입력하세요. 여기에서 이 러너를 프로젝트 전용으로 설정할지 또는 공유할지 선택합니다. 두 가지 옵션 중 이전에 복사한 토큰 중 하나만 입력할 수 있습니다.

• 러너에 대한 설명을 입력하세요:

GitLab 인스턴스 UI에 표시될 CI 러너의 설명이 포함된 이름을 선택하세요.

• 실행기를 입력하세요: custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

여기서는 작업을 실행할 실행기를 선택할 수 있는 옵션을 제공합니다. 입력하세요: Docker.

• 러너의 태그를 입력하세요(쉼표로 구분):

이 항목은 선택 사항입니다. 이 러너가 포함하는 종속성과 같은 태그 이름을 입력할 수 있습니다. 지금은 빈칸으로 남겨두셔도 됩니다.

• 기본 Docker 이미지를 입력하세요(예: ruby:2.6):

여기서는 gitlab-ci.yml 파일이 이미지를 지정하지 않은 경우 작업을 실행하는 데 사용할 기본 범용 이미지를 지정해야 합니다. 입력하세요: alpine:latest 작고 다목적이며 안전한 이미지이기 때문입니다. Enter 키를 누르면 러너가 자동으로 등록되고 시작됩니다:

현재 사용 가능한 러너 목록을 보려면 다음 명령을 입력하세요:

6단계: GitLab에 CI 러너가 성공적으로 연결되었는지 확인하기

다음으로, 브라우저로 돌아가 GitLab 인스턴스의 프로젝트 페이지를 방문합니다. 러너를 등록한 후 몇 분이 지났는지에 따라 작업이 현재 실행 중인 것을 볼 수 있습니다:

또는 이미 완료되었을 수도 있습니다:

그 후, 다음으로 이동합니다: Pipelines 페이지(왼쪽 메뉴의 CI/CD > Pipelines)를 이용하거나, running, passed, 또는 failed 아이콘(파이프라인에 오류가 발생한 경우)을 클릭하여 CI 실행 상태를 볼 수 있습니다. 여기에서 단계 중 하나인 (빌드 단계)가 통과한 반면, 다른 하나는 여전히 실행 중인 것을 볼 수 있습니다:

표의 Stages 헤더 아래에서 단계 아이콘 중 하나를 클릭하여 관련 작업을 확인합니다:

그런 다음 팝업에서 작업을 클릭하여 세부 정보를 확인합니다:

작업이 실행되었으며, 다음이 실행될 때 진행 상황을 볼 수 있습니다: npm 명령어가 종속성을 설치하고 있었습니다. 오른쪽에서 다른 관련 정보를 확인할 수 있습니다. 작업에서 아티팩트를 다운로드할 수 있는 옵션이 있습니다. 드롭다운에서 다른 작업을 보기 위해 단계 간에 전환할 수도 있습니다.

여기에서 테스트 단계의 작업을 선택할 때 표시되는 테스트 케이스를 확인할 수 있습니다:

사용 가능한 러너

왼쪽 메뉴에서 설정 > CI/CD를 클릭하고, 다음을 확장합니다: 러너 섹션 아래에 나타나며, 방금 등록한 러너를 볼 수 있습니다. 프로젝트 전용 토큰을 지정했는지 또는 공유 토큰을 지정했는지에 따라 러너가 각각 해당 섹션에 표시됩니다.

여기서 프로젝트 전용 토큰을 등록한 것을 확인할 수 있습니다. 러너는 Specific Runners:

결론

이 튜토리얼에서는 GitLab CI를 사용하여 테스트를 자동화하는 방법을 배웠습니다. 먼저 GitLab에서 Node.js 앱 프로젝트를 설정하는 것부터 시작했습니다. 프로젝트에는 몇 가지 테스트 케이스와 gitlab-ci.yml 파일이 포함되어 있었습니다. 우리는 GitLab이 gitlab-ci.yml 파일은 트리거되었을 때 수행할 작업을 결정합니다. gitlab-ci.yml 파일은 애플리케이션 빌드 및 테스트에 대한 지침이 포함된 구성 파일로, YAML 형식으로 작성되어 GitLab CI 러너가 이해할 수 있습니다.

또한 별도의 호스트에 GitLab CI 러너를 설정했습니다. 트리거가 발생할 때마다 GitLab 인스턴스에서 작업을 가져오도록 등록했습니다. 이 프로젝트는 간단했지만, 이 정보를 바탕으로 복잡한 프로젝트를 위한 파이프라인을 구축할 수 있습니다. GitLab에 프로젝트를 추가하고 GitLab CI 러너를 연결하는 단계는 동일하게 유지됩니다. 변경되는 것은 gitlab-ci.yml 파일의 지침과 단계입니다.

즐거운 컴퓨팅 되세요!