Gitlab 10.x 삽질기

Upgrade

8.x 로 쓰다가 10.x 로 업그레이드를 진행했다. 아니.. 그런데 Postgresql Database 버전이 다르다고? 알고보니 이렇게 대격변을 일으키면 안 되던 거였다. 그래서 겸사겸사 9.5.10 으로 다시 설치하니까 된다.

gitlab-ctl reconfigure 를 설치 직후에 반드시 해 줘야 한다.
가끔 gitlab-ctl pg-upgrade 를 꼭 하라는 말이 있던데, 내가 해보니까 gitlab-ctl reconfigure 할 때 알아서 한다 (…) 했던 거 또 하는 느낌.
gitlab-ctl restart 를 할 때 postgresql 이나 다른 곳에서 ‘down, up, want up’ 이런 게 뜨면 서비스가 온전히 수행될 수 없는 상황이다. gitlab-ctl tail 을 실행시켜 로그를 뒤져봐야 한다. 에러가 났거나, 무한히 반복되는 메시지가 없는지 확인하자.

Runner

우리 회사 Gitlab 구조는 웹 서비스 주소와 내부 공유 주소가 다르다. (도메인을 거의 리다이렉트 비슷하게 해놨기 때문이기도 하지만) 비공개 저장소다 보니, 웹 접속은 외부에서 되었면서 Clone 은 똑같은 주소로 절대 받을 수 없게 해 놨다. 이게 Gitlab Runner 를 바보로 만들었다 (…)

Gitlab Runner는 .gitlab-ci.yml 의 구성에 상관없이, 선작업으로 해당 저장소를 Cloning 하거나 Fetching 하게 된다. (양자택일은 웹 페이지의 Runner 관리 페이지에서 설정이 가능하다.) 이건 Runner의 Executer를 Docker를 하던 Shell 을 하던 똑같다. 문제는 내가 언급했던 대로, 이 저장소 주소를 웹 주소에 기반해서 가져가기 때문에, 항상 실패했다는 것이다.

짜증이 치밀 즈음, 아예 이 작업을 끌 수는 없을까 하고 봤더니… 역시나 답은 있었다.

variables:
  GIT_STRATEGY: none

이렇게 두면, Runner의 옵션을 Cloning 으로 줬건 Fetching 으로 줬건 간에 하지 않는다.

즉, 모든 작업을 온전히 CI 명령에 맡기는 것이다. 위험하기도 하고, 캐싱도 안 되고 약점이 많지만, 나는 상관이 없었다. 직접 내부 주소의 저장소로 접근해서 받아오면 그만!

Repository 에 SSH Key 등록

그런데, 문제가 생겼다. 아래와 같이 ‘gitlab-runner’ 사용자로 Runner Service를 등록하고, 실행시켰다고 가정하자.

gitlab-runner install --user gitlab-runner
gitlab-runner start
ps aux | grep gitlab-runner # gitlab-runner run 이 잘 되고 있어야 한다.

나는 Executer를 Shell 로 쓰고 있는데, 이 친구가 내부 저장소로 (그것도 SSH 주소로) 접근하려면… SSH Public Key를 넣어줘야 된다. 넣지 않으면 인증에서 실패한다. 그런데 Gitlab Runner 의 Shell 사용자는 위에서 보이는 것 처럼 ‘gitlab-runner’ 인데.. 얘는 Gitlab 계정도 없는 가상 사용자다. 어떻게 Public Key를 등록할까?

Gitlab은, 각 사용자 계정의 SSH Public Key를 관리해 주기도 하지만 Project 별로 SSH Key를 등록할 수도 있다. Project 페이지의 Settings > Repository 에서 Deploy Keys 부분을 펼쳐보자. 그러면 익숙한 SSH Key 등록 폼이 나온다. 여기에, 아까 언급한 ‘gitlab-runner’ 의 SSH Key를 등록하면 된다. (당연히 gitlab-runner 계정에서 SSH Key 생성을 해야한다.)

그러면.gitlab-ci.yml 에 마구잡이로 'git clone git@~~~~:<user or group>/<project>.git' 이런 식으로 스크립트를 적어도 아주 잘 clone 되는 걸 확인할 수 있다!

Create New Branch 의 기본 Branch 바꾸기

Issue 페이지에서 Create New Branch (9.x 에서는 New Branch) 를 하면, Branch의 이름이 ‘421 – invalid table error’ 이런 식으로 뜬다. 이슈 번호와 이슈 제목.

그런데 내부적으로는 이슈 제목에 한글을 많이 써서 Branch 이름을 출력하고 싶지 않았다. 그리고 규격화된 이름 (ISSUE#XXXX) 으로 Branch를 생성하고픈 욕구가 치밀었다. (참고로 Push Rule 에서 Branch Naming Rule에 저렇게 규칙을 쓰고, Create New Branch 를 누르면 절대로 Branch가 생기지 않는다.)

Gitlab에 이미 #21143 으로 이슈가 등록되었고, 10.3 에서 업데이트가 된다지만… 이렇게 되면 사용자가 매번 Push Rule을 피하려고 Branch 이름을 일일이 쳐넣는 어처구니없는 상황이 계속된다. 그래서 코드를 찾아내서 고치는 편이 낫다고 생각했다.

Ruby는 쥐뿔도 모르지만 코드는 코드일 뿐.

이슈에 대한 브랜치를 생성하는 작업은 이 Merge Request 에서 반영된 것이다. 여기 Diff를 쭉 봤더니 to_branch_name 이 눈에 띈다. 오호라. 하지만 어디서 수정해야 할까?

Gitlab을 Omnibus 로 정직하게 설치했다면 소스코드 경로는 /opt/gitlab/embedded/service/gitlab-rails/ 에 있다. 여기서 grep으로 to_branch_name 을 검색해 보면?

cd /opt/gitlab/embedded/service/gitlab-rails/
grep to_branch_name . -rn
# ./embedded/service/gitlab-rails/app/models/issue.rb:XXX def to_branch_name
# 이하 생략
vi app/models/issue.rb

여기서 "#{iid}-#{title.parameterize}" 라고 정의된 부분을 적절히 바꿔주자. 나는 "ISSUE##{iid}" 로 심플하게 바꿨다.

이것만 바꾸면 ‘Create New Branch’ 를 누를 때 잘 될 것 같다. 하지만 Issue 페이지에서 ‘연관된 Issue Branch’ 목록에 연결되지 않는다. 수정한 파일 /opt/gitlab/embedded/service/gitlab-rails/app/models/issue.rb 에서, 더 수정할 것이 남아있다. 다음 함수를 수정해야 한다.

has_related_branch
related_branches

수정 방법은 간단한데, Branch와 비교하는 Regular Expression 의 문법을 찾아보자. /\A${iid}-(?!\d+-stable)/i 라고 되어 있을 것이다. 이걸 실제로 irb 에서 테스트해 보면, 420-title 같은 건 되는데 420-0-stable 은 인식이 안 되는 것을 알 수 있다. (뭔가.. 이상하다) 아무튼 이걸 적절한 Regular Expression 으로 바꿔 주도록 하자. Ruby의 Regexp 에 익숙치 않다면 Rubular 사이트의 도움을 받아보도록 하자. (내 경우는 간단하게 /\AISSUE#{iid}/i 라고 했다.)

수정을 했다. 하지만 끝이 아니다. 마무리를 해 줘야 한다. 실제 Gitlab이 서비스되고 있는 경로는 /var/opt/gitlab 이므로, 해당 경로로 적용을 시켜줘야 한다. 어떻게?

간단하다. gitlab-ctl reconfigure && gitlab-ctl restart 를 입력하자.