[OpenStack에 contribute하기 - 5] Gerrit 사용하기 (1)

이번에는 우리가 OpenStack에 contribute하기 전에 Gerrit을 어떻게 사용해야 하는지 알아볼 것입니다.

---

 

Gerrit 흐름도

---

위의 그림은 Gerrit을 통한 코드 리뷰의 흐름을 나타낸 것입니다. 위의 그림을 간단하게 설명하자면 다음과 같습니다.

1. 코드를 수정하고자 하는 프로젝트를 로컬 환경으로 clone합니다.
2. 로컬 환경에서 수정하고자 하는 버그에 대해서 브랜치를 생성합니다.
3. 변경사항에 대해 저장하고, 유닛 테스트를 진행한 다음, git commit을 실행합니다. (가장 첫 번째 커밋만 git commit으로 로컬 환경에 변경사항을 저장합니다.)
4. git review를 통해 Gerrit 리뷰시스템에 변경사항을 제출합니다.
5. 자동 테스트 툴을 통해, 빌드 및 테스트를 진행하고, 제출한 코드를 리뷰 받습니다.
6. 기존의 변경사항을 다시 수정해야할 경우, 코드를 변경하고 git commit --amend를 통해 다시 변경사항을 제출합니다. (반드시 --amend 옵션을 붙여야합니다.)

 

 

Bug에 대해서 작업하기

---

하나의 프로젝트에 대해서 버그 리포트는 Launchpad(https://bugs.launchpad.net/<프로젝트>)나 StoryBoard(https://storyboard.openstack.org)에 기록됩니다. 컨트리뷰터들은 정기적으로 완료할 작업을 찾을 때 이러한 버그 리포트들을 리뷰할 것입니다.

버그 상태에 대한 정보는 여기에 문서화 되어있습니다: https://docs.openstack.org/project-team-guide/bugs.html

작업하고싶은 버그를 발견한다면 그 버그를 자신에게 할당해도 됩니다. 리뷰를 업로드 할 때, Launchpad와 StoryBoard에 자동 업데이트를 위해서 커밋 메시지 속에 버그를 포함시키세요. Launchpad에서 사용 가능한 옵션은 다음과 같습니다.

Closes-Bug: #######
Partial-Bug: #######
Related-Bug: #######

그리고 StoryBoard에서는 다음과 같습니다.

Task: ######
Story: ######

 

변경사항 시작하기

작업을 저장할 브랜치를 생성하고, 그 브랜치로 전환하세요. 만약 blueprint에 대해서 작업하고 있다면, 브랜치의 이름을 bp/BLUEPRINT로 설정하세요. 여기서 BLUEPRINT는 Launchpad에서 blueprint의 이름입니다. (예: bp/authentication) 버그에 대한 일반적인 관습은 브랜치의 이름을 bug/BUG-NUMBER로 지정하는 것입니다. (예: bug/1234567)

git checkout -b TOPIC-BRANCH

 

변경사항 커밋하기

커밋 메시지의 타이틀은 50자 이내로 작성해야 합니다. 그 다음에 오는 문단은 변경사항에 대해 더 자세하게 설명해야 합니다.

만약 변경사항이 blueprint 또는 버그를 처리하는 경우, 다음 구문을 사용해서 커밋 메시지 안에 언급하도록 하세요.

Implements: blueprint BLUEPRINT
Closes-Bug: ####### (Partial-Bug or Related-Bug are options)

예를 들면 다음과 같습니다.

Adds keystone support

...Long multiline description of the change...

Implements: blueprint authentication
Closes-Bug: #123456
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657

대부분의 경우 git-review가 설치한 Gerrit 커밋 훅에 의해서 Change-Id 라인이 자동으로 추가되는 점에 유의하세요. 이미 커밋을 했는데 Change-Id가 추가되지 않은 경우 Gerrit 설정 단계를 다시 수행하고 다음 명령을 실행하세요: git commit --amend. 커밋 훅은 우리가 실제로 아무 변경사항도 만들지 않았어도, 커밋 메시지 수정을 마치면 자동으로 Change-Id를 추가합니다. Change-Id는 절대로 변경하지 마세요. Gerrit이 혼동할 수 있습니다.

변경사항을 만들고, 커밋하세요. (아직 리뷰를 제출하지는 않았습니다.)

git commit -a

마스터 브랜치에서 변경사항을 만들지 마세요. 그렇게 하면 upstream으로부터 새로운 변경사항을 pull 할 때 충돌이 발생하고, merge 커밋은 Gerrit에 의해 거절됩니다.

 

Unit Test 실행하기

변경사항을 제출하기 전에, 우리는 꼭 테스트를 해봐야 합니다. OpenStack 프로젝트에서 파이썬 기반 유닛 테스트를 실행하는 법을 배우려면 다음 주소를 참고하세요: Running Python Unit Tests

 

리뷰를 위해 변경사항 제출하기

로컬 레포지토리로 변경사항을 커밋했다면, 코드 리뷰를 위해 Gerrit으로 전송하기 위해 필요한 것은 다음 명령어 한 줄이면 됩니다.

git review

위의 작업이 끝나면 제출한 변경사항에 대해 자동화 된 테스트가 실행될 것이고, 다른 개발자가 검토를 할 것입니다.

 

변경사항 업데이트 하기

만약 코드 리뷰 과정에서 추가적인 변경을 제안하는 경우, 기존 커밋을 변경하고 수정하세요. 커밋 메시지 아래에 있는 Change-Id 줄은 그대로 두세요. Gerrit은 이것이 기존 변경사항에 대한 업데이트된 패치셋이라는 걸 알고있습니다.

git commit -a --amend
git review

 

본 포스트는 다음 주소를 참고하였습니다.

• https://docs.openstack.org/infra/manual/developers.html
• https://docs.openstack.org/contributors/code-and-documentation/using-gerrit.html