4 posts tagged with "gerrit"

Google의 code review tool인 Gerrit 사용시 기존의 label인 Code-Review, Verified 이외에 사용자 정의 label이 필요한 경우가 있다.

내 경험으로는 CI를 위해 custom label이 필요했었는데 특정 label의 point로 build 여부를 결정짓는데 사용했다.

Custom label이 필요한지 여부를 판단하는 것은 어디까지나 SCM 정책에 따라 달라질 수 있고 그 설정과 관리는 대부분의 사용자들과는 관계가 없는 부분이다.

 

1. Project clone​

Custom label을 적용하고자 하는 특정 project (저장소)를 clone 한다.

Gerrit의 branches 메뉴를 보면 refs/meta/config 라는 reference가 존재하는데 일반적으로 master branch가 항상 있는 경우 refs/meta/config를 checkout 하지 않으면 보이지 않는다.

비어있는 project를 대상으로 하면 (branch가 없음) clone 하면 바로 유일한 reference인 refs/meta/config의 내용이 나타난다.

 

2. project.config 수정​

refs/meta/config에는 project.config와 groups 파일이 있는데 (모든 경우를 살펴본 것은 아니라서 다른 파일이 추가되어 있을 수도 있음)

groups 파일에는 access control에 추가되어 있는 관계된 group 정보가 포함되어 있고 custom label 설정과는 관계가 없다.

project.config 파일을 열어보면 access control에 대한 내용과 project 일반적인 설정들이 포함되어 있는데 (description 등) 추가할 label에 대한 내용을 정의한다.

보통 이런 형태로 작성하면 되는데

[label "test label"]

function = NoOp

value = 0 Do Not Build

value = +1 Build Now

추가 상세 설정은 Gerrit 문서를 참조해서 진행한다.

function을 NoOp으로 설정한 경우 submit 여부를 결정하는데 test label이 영향을 미치지 않는다. (기존 정책에 따라 submit 여부가 결정됨)

value는 설정한대로 부여할 point의 범위가 결정되는 역할을 한다.

 

3. Commit / Push​

소스코드와 동일하게 저장소 변경사항이 발생했으므로 commit을 하고 push를 한다. (Push 할 때 refs/meta/config를 지정하는 것은 기본)

Gerrit의 branches 에서 refs/meta/config의 내용을 확인해 변경사항이 제대로 반영되었는지 확인이 되면 Access Control 메뉴에서 설정할 때 내가 추가한 test label 설정이 가능한 것을 확인할 수 있다.

 

4. 결론​

일반 개발자들이나 사용자들은 어쩌면 알 필요가 없는 기능이다.

하지만 이런 것도 Gerrit이 제공한다.

알아두면 CI 구성이나 SCM 정책을 좀 더 유연하거나 강화시키는데 도움이 될것이라고 본다.

국내에서는 이런 custom label 사용보다 사실 Gerrit이 제공하는 기본 기능, 정책들만이라도 잘 지킬 수 있기를 희망한다.

GIT 설정을 따로 할 일이 별로 없었는데 repo까지 사용하는 환경에서 자동화 하다보니 필요해졌고, 공식 페이지가 진리라 따로 부연할 꺼리도 없지만 이번에 사용해 본 설정만이라도 정리해보기로 했다. 최소한 이런 설정을 어떤 경우에 사용할 수 있는지라도 설명이 될 수 있을 것 같다.

1. 상황

언급했듯이 repo를 사용하는 환경이다. repo에 대해서 간단히 설명하자면, 여러개의 GIT 저장소를 가지고 빌드를 하거나 개발을 할 때 편의를 제공하기 위해 Google에서 만든 툴로 AOSP (Android Open Source Project)에서 사용되고 있다. Python으로 개발된 script의 모음이고 manifest 내부를 보면 어느 저장소를 어느 경로에 갖다 두는지에 대한 내용들이 주를 이루고 있다.

repo 이외에 Gerrit도 사용하고 있다. Gerrit은 역시 AOSP에서 사용되는 Code Review 툴로 code review 이외에 다른 기능을 위해 사용하는 것도 가능하다. (예를 들면 코드 검증, review 만을 위해서가 아니고)

저장소를 Gerrit에 연결하기 위해서는 Gerrit project로 등록을 해야 하는데, 등록이 되면 저장소 별로 따로 사용자 인증에 필요한 절차를 수행할 필요 없이 Gerrit에서 관리가 가능해진다.

이 부분도 Gerrit의 장점이라고 할 수 있다. GIT을 쓰면서 제일 불편한 것중 하나가 사용자 인증과 관리니까. 또 그래서 여러가지 툴들도 꽤 등장했다. Gitblit, Gitlab, 등등. 서비스에서도 그런 기능을 제공하기도 한다. 많이 쓰고 있는 github이 그 예가 될 것이고.

Gerrit 설정이 갑자기 바뀌면서 repo init을 할 때 command 형태를 변경해야만 했는데 (계정과 gerrit의 port를 추가해야 했다. 일반적으로 별도 설정없이 Gerrit을 그대로 쓰면 계정과 port 정보를 꼭 넣어줘야 하는데 이곳 환경에서는 최초에 없어도 되었었지만, 추가해야 하는 형태로 다시 변경되었음), 문제는 init을 하더라도 manifest 파일에는 계정과 port 정보가 빠져있는 형태의 대표 url만 기록되는 곳에서 발생했다. repo sync 이전에 manifest 파일을 열어서 fetch url 부분을 수정해야만 했다.

2. 조치

원래 나와 같은 위치에 있는 사람들에겐, 대다수가 권한과 정보에 대해서 상당히 인색한 편이다. 아쉬울게 없다. 나만의 해결책을 만들어서 보고하고 마음에 들지 않으면 이슈로 제기하면 되니까. 그래서 처음엔 script를 만들었다. manifest 파일을 수정하는 script. 처음엔 만족스러웠지만 사실 manifest를 수정한다는건 (자동이든 수동이든) 부담도 있고 비효율적이다. 결국은 GIT config를 변경해서 script를 사용하지 않고도 문제를 해결할 수 있었다.

3. GIT config의 종류

Gerrit / repo 모두 GIT을 사용하기 때문에 GIT 설정만으로도 위의 문제를 해결하는게 가능한데, 우선 GIT의 설정은 크게 세 가지로 나뉜다.

local, global, system 설정이 그것인데 각각 저장소 대상 개별 설정, 사용자 대상 설정, 전체 사용자(시스템) 대상 설정을 의미한다.

git config 명령에 option으로 설정 범위를 선택하는게 가능한데 설정된 내용은 각각 $GIT_DIR/config, ~/.gitconfig, $(prefix)/etc/gitconfig 파일에 기록된다.

그러므로 config 명령을 사용하기 싫으면 각각의 파일을 직접 수정해도 무방하다.

4. GIT url insteadof 설정

아래와 같은 형태의 설정을 하면 GIT으로 요청하는 모든 url 중에 해당되는 url을 대체하는게 가능하다

url.<base>.insteadOf (당연히 대소문자 구분)

예를 들어, http://test.com에 대한 요청을 ssh://test@test.com:29418 로 변경하고자 한다면 이렇게 설정하기만 하면 간단히 정리된다.

git config --global url.ssh://test@test.com:29418.insteadOf http://test.com

 

이렇게 해결.

그런데 설정 형식이 조금 못생겼다는 생각을 지울수가 없다. 마침표를 왜 넣지? 다른 방법도 있었을텐데.

Gerrit을 처음부터 설정해 사용하면서 느끼는 문제점들이 몇가지 있다.

 

1. 사용자 추가​

Gerrit 설정시 로그인과 관련해서 지원하는 몇 가지 방법이 있다.

그 중 OpenID와 LDAP을 가장 많이 쓸 것이라고 생각하는데 우리네 환경에서는 OpenID를 사용하기가 힘들다. (보안 이슈)

그래서 AD 서버와 LDAP으로 연결해서 쓰고는 있는데 이것 이외에 UI 조작으로 사용자 계정 추가를 할 수 있는 방법이 없다.

Command line 으로는 사용자 계정을 추가할 수 있는데 이것도 문제가 좀 많다. (뒤에 언급)

 

2. 사용자 삭제​

UI 상에 사용자 계정 추가가 없기 때문에 삭제 역시 없다.

 

3. Command Line Interface​

먼저 계정 생성 command인 create-account.​

생성은 된다. 하지만 생성이 제대로 되었는지 response가 없다.

무반응이면 제대로 되었나보다 생각하면 되는데 password 설정이 안된다.

http-password 라는 옵션이 있어서 거기에 password를 넣으면 되나 싶었는데 로그인하면 되질 않는다. (이것은 로그를 충분히 확인해볼 필요가 있겠다 싶은데 아직은 로그 확인 전)

create-account의 옵션 중에 있는 group은 공백을 인식하지 못하는 것으로 보인다.

큰따옴표로도 묶어봤으나 여전히 인식이 안된다.

add-ssh-key 옵션이 있는데 인자로 파일명을 주면 안된다.

지금까지 확인한 바로는 stdin만 먹는 것으로 보인다.

 

멋진 사용자 계정 삭제 command.​

유감스럽게도 없다.

여기저기 찾아보면 inactive로 만들라고 권고하는 것 같은데 inactive는 로그인만 못하게 막는 것이지 계정을 지우는게 아니기 때문에 만약 짜증나는 계정 foo를 삭제하고 다시 만들려고 해도 안된다. foo2 등의 이름으로 다시 만들 수 밖에.

 

이해 안되는 set-account.​

계정 삭제가 안되니 이리저리 다시 세팅해서 계정을 쓰려고 했는데 재미있는 사실을 발견했다.

바로 add-ssh-key와 delete-ssh-key 옵션에서 문제를 발견했는데 이미 추가한 ssh-key를 지우려고 편하게 delete-ssh-key ALL (ALL은 제공하는 값이다. 해당 계정의 모든 ssh key를 지우라는)을 입력했는데 역시나 response 없이 command가 실행되었다. 그래서 문제없겠거니 생각하고 add-ssh-key로 새로운 ssh key를 추가했는데 역시나 no response. 제대로 설정 되었는지 확인하려고 ssh key 삭제 전에 잘 되던 저장소 clone을 해봤더니 public key 문제로 불가. ssh key를 다시 만들고 별 쇼를 다 해봐도 안된다. 또 다른 계정 xxx2 등으로 또 만들어서 쓸 수 밖에.

 

4. 관리자 계정​

왜 그런건지 모르겠지만 갑자기 오늘 오전부터 관리자로 설정되어 있던 내 계정이 관리자가 아닌 걸로 인식을 하고 있었다.

도저히 알 수가 없어서 db를 다시 만들어서 설정했다.

 

결론​

현재까지의 상태들을 종합하면 gerrit은 계정관리 부분이 취약하다. 뭔가 대단히 불편한데, 불편한 건 이해하고 넘어가더라도 원인을 파악할 수 있는 수단이 거의 없어서 해결할 방법을 찾기가 힘들다.

참고로 이 모든 현상이 만들어지고 있는 gerrit의 버전은 무려 2.5.1이다. 1.0도 아니고 1.5도 아니다.

구글 내부적으로 쓰는거라 그런건지도 모르겠지만, made by Google 이라고 맹신해서는 안된다는 걸 느낀다.

Code Review tool인 gerrit 설치를 했다.

문서상으로는 설정을 해야 하는 것들이 상당히 많았다.

꼭 필요한 부분만 내용을 채우고 로그인에 필요한 ldap 설정까지 끝냈는데 gerrit start 후 로그인을 하니 리다이렉션이 너무 많다는 오류와 마주치게 되었다.

 

Redirect 된 마지막 주소를 보니

http://[my_host_name]:[port]/login/q/null#/q/null

이런 형태.

 

null이 왜 붙어있는건지 알 수 없어서 찾아보니 버그란다.

[http://goo.gl/QKmCT

](http://goo.gl/QKmCT)

 

etc/gerrit.config의 [gerrit] 항목에 canonicalWebUrl 항목을 추가해주면 해결.

 

[html]

[gerrit]

canonicalWebUrl = http://my.example.com:port

[/html]

 

참고로 내 환경은 apache 같은 별도의 웹서버에 얹어서 사용하지 않으며, ldap 설정만 했다.

port, host name 등은 내 환경에 맞게 설정한 상태.

어쨌거나 gerrit은 첫인상이 별로다.