Gitlab CI 시작하기

2016-06-20 시점에 http://docs.gitlab.com/ce/ci/quick_start/README.html 에 기술된 내용을 번역합니다.

NOTE: Gitlab Continuous Integration (CI)는 8.0 버전부터 Gitlab에 통합되어 있고 모든 프로젝트에서 default로 활성화되어 있습니다.

Gitlab CI가 어떻게 동작하는지에 대한 TL;DRfootnote:[Too Long; Didn’t Read] 버전의 설명은 다음과 같습니다.

Gitlab은 continuous integration 서비스를 제공합니다. 당신의 repository 최상위 폴더에 .gitlab-ci.yml 파일을 추가하고 Gitlab 프로젝트를 Runner를 사용하도록 설정하면 각각의 merge request 또는 push 시 build가 시작됩니다.

.gitlab-ci.yml 파일은 Gitlab runner에게 무엇을 해야 할 지를 알려줍니다. 보통 runner는 build, test, deploy의 3개 stage로 동작합니다.

문제없이 동작했다면(0이 리턴된다면!) 예쁜 초록색 체크마크가 push commit 또는 merge request에 붙게 됩니다. 이는 코드를 보지 않고도 해당 commit 또는 merge request가 테스트를 패스했는지 여부를 알 수 있게 합니다.

많은 프로젝트들이 Gitlab CI 서비스를 test suite를 돌리는 데에만 사용하므로 개발자들은 문제가 있을 때 즉각 feedback을 받을 수 있습니다.

요약하면 CI를 동작시키기 위해서는 다음 두 스텝을 수행해야 합니다.

.gitlab-ci.yml을 repository의 최상위 폴더에 add(git operation).
Runner를 설정.

이 후로 Git repo에 올리는 모든 push마다 Runner에 의해 build가 자동적으로 수행되고, 이는 각 프로젝트의 /builds 페이지에 나타납니다.

이 가이드는 아래 내용을 가정합니다.

8.0 이상의 Gitlab을 설치해서 사용, 또는 Gitlab.com 을 사용.
CI를 사용하고자 하는 Gitlab 프로젝트를 갖고 있음.

하나하나 쪼개어서 Gitlab CI 퍼즐을 풀어봅시다.

`.gitlab-ci.yml` 파일 생성하기

.gitlab-ci.yml을 만들기 전에 이 팔일이 어떤 일을 하는지 설명하겠습니다.

`.gitlab-ci.yml`이란?

.gitlab-ci.yml 파일은 CI가 프로젝트에서 어떤 일을 할지를 설정하는 곳입니다. 이 파일은 당신의 repo에서 root directory에 위치합니다.

Repo에 올리는 모든 push마다 Gitlab이 .gitlab-ci.yml을 찾아서 해당 내용에 따라 해당 commit에 대해 Runner 위에서 build를 시작합니다.

.gitlab-ci.yml 파일은 repo에 포함되기 때문에 버전 컨트롤됩니다. 그러므로 빌드 룰이 변경되어도 이전 버전도 정상적으로 빌드되며 fork 프로젝트도 CI를 쉽게 사용할 수 있습니다. 또한 하나의 단일 소스에 대해서 branch를 이용하여 여러개의 build를 가질 수 있습니다.

NOTE: .gitlab-ci.yml은 YAML 파일이므로 indentation에 유의해야 합니다. Tab을 사용하지 마시고 항상 space를 사용해 주세요.

간단한 `.gitlab-ci.yml` 파일 만들기

Repo의 root에 .gitlab-ci.yml 파일을 생성해야 합니다. 아래는 Ruby On Rails 프로젝트를 위한 예제입니다.

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-ri --no-rdoc
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

rspec:
  script:
    - bundle exec rspec

rubocop:
  script:
    - bundle exec rubocop

이는 대부분의 Ruby 어플리케이션에서 동작할 수 있는 가장 간단한 build configuration입니다.

. rspec, rubocop이라는 이름의(이름은 임의로 정할 수 있습니다) 2개 job을 각각 다른 command가 수행하도록 설정합니다. . 모든 job을 수행하기 전에 before_script에 define된 command들이 수행됩니다.

The .gitlab-ci.yml file defines sets of jobs with constraints of how and when they should be run. .gitlab-ci.yml 파일은 job들이 어떻게, 또 언제 실행되어야 하는지를 기술합니다. Job은 yml의 top-level element로 정의되고(위 예제에서는 rspec과 rubocop), 이는 항상 script keyword를 갖고 있어야 합니다. Job은 build를 생성할 때에 사용됩니다. Runner에 의해 선택되고 Runner 구동 환경에서 수행됩니다.

각 job이 독립적으로 수행되는 것이 매우 중요합니다.

.gitlab-ci.yml 파일의 validity를 체크하고자 하는 경우 /ci/lint 페이지 아래에 Lint tool이 준비되어 있습니다. Settings > CI settings 에서 링크를 확인하실 수 있습니다.

.gitlab-ci.yml 문법에 대해서는 .gitlab-ci.yml 문서를 참고해 주세요.

`.gitlab-ci.yml`을 GitLab에 푸쉬하기

.gitlab-ci.yml 파일을 생성했다면 git repo에 add한 후 Gitlab에 push합니다.

git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master

이제 Builds 페이지에서 pending된 build를 확인할 수 있습니다.

또한 Commits 페이지에서 commit SHA 좌편에 작은 clock 아이콘을 확인할 수 있습니다.

Clock Icon on New Commit

시계 icon을 클릭하면 해당 commit의 build 페이지로 이동합니다.

Single Commit Status Pending

.gitlab-ci.yml 파일에 정의한 2개 job이 pending된 것이 보입니다. 빨간 삼각형은 아직 이 build들에 대해 Runner가 설정되어 있지 않다는 표시입니다.

이제 pending job을 pick할 수 있도록 Runner를 설정할 차례입니다.

Configuring a Runner

Runner가 .gitlab-ci.yml에 정의된 build를 수행합니다. Runner는 virtual machine, VPS, bare-metal machine, docker container 또는 cluster of containers일 수 있습니다. Gitlab과 Runner는 API를 통해 communication합니다. 그러므로 Runner가 수행되는 machine은 internet access만 가능하면 됩니다.

Runner는 특정 project에만 사용 가능하도록, 또는 여러 project에서 사용 가능하도록 설정할 수 있습니다.

모든 프로젝트를 serve하는 프로젝트를 Shared Runner라고 합니다.

Find more information about different Runners in the Runners documentation. 다른 runner에 대한 추가 정보는 Runner 문서를 참고 바랍니다.

You can find whether any Runners are assigned to your project by going to Settings > Runners. Setting up a Runner is easy and straightforward.

Settings > Runners 페이지에서 프로젝트에 어떤 runner가 assign 되었는지 확인할 수 있습니다. Runner의 셋팅은 매우 쉽고 직관적입니다.

Gitlab에서 제공하는 공식적인 Runner는 Go로 작성되었고 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner 에서 확인할 수 있습니다.

Runner가 동작하도록 하기 위해 다음 두 스텝이 필요합니다.

특정 프로젝트를 위한 개별 Runner를 설정하려는 경우 위 링크를 참조하세요. Shared Runner는 다음 섹션의 설명을 참고 바랍니다.

다른 언어로 작성된 비공식 Runner는 https://about.gitlab.com/gitlab-ci/#gitlab-runner 에서 확인할 수 있습니다.

Runner를 한 번 설정하고 나면 Settings > Runners 에서 이를 확인할 수 있습니다.

Runner Activation Check

Shared Runners

GitLab.com 유저라면 Gitlab Inc.에서 제공하는 Shared Runners 를 사용할 수 있습니다.

이는 GitLab’s infrastructure 위에서 동작하며 어떤 프로젝트라도 다 빌드할 수 있는 특별한 virtual machine입니다.

Shared Runners를 활성화하려면 프로젝트의 Settings > Runners 페이지에서 Enable shared runners를 클릭하세요.

Shared Runner에 대한 더 상세한 설명은 http://docs.gitlab.com/ce/ci/runners/README.html 를 참고 바랍니다.

Build의 status 보기

Runner를 성공적으로 설정했다면 마지막 commit의 status가 pending에서 running, success 또는 failed로 변경된 것을 볼 수 있을 겁니다.

또한 프로젝트의 Builds 페이지에서 모든 빌드를 확인할 수 있습니다.

Build Status

Build ID를 클릭해서 해당 빌드의 로그를 확인할 수 있습니다. 이는 왜 빌드가 실패했는지, 또는 예상한 것과 다르게 동작했는지 확인하고자 할 때 필요한 정보를 제공합니다.

Build Log

또한 Commits, Merge Requests 페이지에서 commit들의 상태를 확인할 수 있습니다.

빌드 email 활성화

If you want to receive e-mail notifications about the result status of the builds, 빌드 결과를 이메일로 알림받으려면 프로젝트 셋팅에서 Builds Emails service를 활성화해야 합니다.

자세한 정보는 Builds emails service documentation를 확인하세요.

Build 뱃지

Build 뱃지 이미지는 다음 링크에서 확인할 수 있습니다.

http://example.gitlab.com/namespace/project/badges/branch/build.svg

예제

Visit the examples README에서 다양한 프로그래밍 언어에 대한 Gitlab CI 예제를 확인할 수 있습니다.