GitHub PR (with DCO 봇, GPG 서명, Issue 연결)

 

2024 오픈소스 컨트리뷰션 아카데미 ArgoCD 프로젝트 멘티로 합류하고 나서 별다른 활동이 없었다. 일단 개인적으로 쿠버네티스 책을 읽어보면서 환경에 대한 이해를 하고 있었다. 

 

멘토님들이 공지를 Slack으로 해주신다고 하셨는데 Slack에 별다른 알림이 오질 않아서 혼자 공부만 하고 있었다. 그러다 오늘 혹시나 하는 마음에 Slack에 들어가보니 이미 월요일에 첫 번째 과제를 올려주셨던 것이다..!! 왜 내 Slack은 알람이 오질 않는 것인가? 설정을 다시 해야겠다. 아무튼 첫 번째 과제가 있었다. 

 

첫 번째 과제 공지

 

첫 번째 과제는 GitHub를 이용해서 PR을 생성해보고 merge해보는 작업이었다. 

여러 번의 프로젝트를 하면서 Git과 GitHub을 그럭저럭 다룰 수 있다고 생각했었기에 좀 쉽게 보았다. 

 

하지만 그리 만만하지만은 않았다. GitHub에는 내가 모르는 다양한 기능이 많았고 나는 어려 오류와 부딪히면서 해결해갔다. 

 

과제 대상 레포는 우리 ArgoCD 오픈소스 기여 프로젝트의 소개 페이지였고 node.js 와 markdown으로 작성된 페이지였다. 해당 레포에서는 우리가 브랜치를 생성하거나, push 등의 작업을 하는 것이 제한되어 있었기 때문에 개인 레포지토리로 fork한 다음에 수정 후 PR을 생성해야했다. 

 

우리 Organization 에 있는 레포에 PR을 생성했을 때, 해당 PR이 merge 되기 위해서는 3가지 단계를 거쳐야만 했다. 

1. 멘토님 들에게 review를 꼭 받을 것
2. Test Lint On PR / lint-test 통과할 것
3. DCO 봇의 test 통과할 것
4. 추가적으로 내 커밋에 verified 라는 태그가 붙어있을 것
5. 이슈를 템플릿을 통해 생성하고 키워드 지정 방식으로 PR과 연결지어서 PR이 merge되면 이슈도 같이 없어지도록 할 것

좀 복잡해 보였지만 멘토님들이 이슈 템플릿에 가이드를 좀 상세하게 설명해주셔서 그거 보면서 따라했다. 

생성한 이슈이다. 템플릿 내용 그대로 생성했다.

 

우선 내 레포로 fork하고 local에 git clone 해서 문서를 수정했다. 

내 맥북에는 npm이 깔려있지 않아서 homebrew를 이용해서 npm을 설치해주었다. 

brew install npm

 

 

그리고 커밋을 해야 하는데 서명된 커밋을 작성해 달라는 요청이 있었다. 

 

서명된 커밋이 뭘까?

현재는 내가 로컬에서 commit을 할 때 GitHub username 과 email 정보만 git config 파일에 명시되어 있으면 가능했다. 이 방식의 문제점은 누구나 내 username과 email만 알면 commit, push 등을 자유롭게 할 수 있다는 점이다. 그래서 커밋도 아무나 하지 못하게 암호를 걸어두는 것이다. 

GPG를 이용해서 키를 생성하고 해당 키를 git config --global 에 등록해두면 커밋을 할 때마다 설정해둔 비밀번호를 입력하는 창이 뜬다. 그럼으로써 signed commit을 생성할 수 있다. 

커밋을 아무나 생성하게 하는 것은 막았지만 특정 signed 된 커밋만 원격저장소에 올리는 것은 어떻게 할까? 커밋을 보면 가끔 verified 라고 태그가 달려있는 것들이 있다. 이건 해당 commit 의 서명이 GitHub에 등록한 서명 중에 존재 한다는 것을 의미한다. 

GitHub에서는 GPG의 공개키를 등록해둠으로써 서명을 등록해 둘 수 있다. 설정 > ssh and GPG key 에 들어가서 추가할 수 있다. 그러면 GitHub에서 커밋 로그를 확인할 때, verified라는 태그가 붙어있는 것을 확인할 수 있다. 

 

https://www.44bits.io/ko/post/add-signing-key-to-git-commit-by-gpg#gpg-%ED%82%A4-

%EC%83%9D%EC%84%B1

GPG(GNU PG)를 이용해 git 커밋에 서명하는 방법

 

 

그리고 DCO bot 의 test를 통과해야 한다. 

DCO test는 commit message 에 아래 문구가 포함되어 있는지를 테스트 한다. 없으면 PR을 merge 하지 못한다.  

Signed-off-by: Random J Developer <random@developer.example.org>

https://github.com/apps/dco

GitHub: Let’s build from here

 

 

이렇게 해당 문구가 포함된 서명된 커밋을 생성하고 PR을 생성했다. 지금껏 수동으로 이슈를 PR에 연결지었었는데 이번에 키워드로 해보라고 하셔서 키워드로 처음 해보게 되었다. 난 close #이슈번호 로 지정해주었고 해당 키워드는 PR이 merge 되면 지정된 이슈가 close 시킨다는 뜻이다. 

 

https://docs.github.com/ko/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

끌어오기 요청을 이슈에 연결 - GitHub Docs

 

 

그렇게 PR까지 잘 생성했다. 그리고 멘토님이 일부러 conflict를 발생시켜 주셨고 한 번 해결해 보라고 해주셨다. 

 

 

 

근데 수정하면서 Test Lint On PR 이 실패했다. memers.mdx 파일에서 마지막에 비어있는 라인이 있었는데 내가 충돌을 해결하면서 해당 라인을 지워버리는 바람에 실패했던 것이다. 그래서 해당 라인을 추가해주고 커밋을 또 생성했다. 여기서 커밋을 또 생성하면서 문제가 연속해서 발생했다. 

커밋을 생성할 때 sign-off 부분이 모든 커밋마다 같아야 DCO test를 통과할 수 있는데 내가 새로운 커밋을 생성할 때마다 이를 지키지 않았다. 당시에는 몰라서 다른 부분을 계속 수정하느라 커밋이 여러 개 쌓였다. 결국 멘토님께 여쭈어보았고 원인을 찾을 수 있었다. 

 

PR에 대한 review

 

생성한 모든 commit 에 동일한 sign off 정보를 포함시키든지, squash 를 통해 commit 을 하나로 합친 후 sign off를 한 번만 작성하면 된다고 하셨다. 난 추천해주신 두 번째 방법인 squash를 사용해보기로 했다. 

 

rebase를 사용해서 이전 commit으로 이동한다. 이때 -i 라는 옵션을 주게 되면 포함되는 모든 commit 에 대해서 어떤 작업을 수행할지를 선택할 수 있다. 이때 squash 옵션도 있어서 그걸 사용하는 방식으로 해결했다. 

https://deku.posstree.com/ko/git/git-squash/

Git squash로 여러 커밋을 하나로 만들기

 

 

 

잘 해결되었다. 

 

GitHub를 나름 여러 번 사용해보았고 나름대로 좀 쓸 줄 안다고 자부하고 있었는데 GitHub에는 생각보다 많은 기능이 있었고 내가 사용하던 기능은 정말 새발의 피였다. member 마다 권한을 제한할 수 있다는 것을 들어보기만 했었는데 직접 겪어본 것은 처음이었다. 

 

그리고 review의 순기능에 대해 몸소 느낄 수 있었다. 프로젝트를 하면서는 주로 대면으로 하는 것을 선호했기 때문에 구두로 review를 진행하는 경우가 많았다. review는 귀찮았고 하지 않았기에 PR을 하는 것의 의미가 크게 없었다. 이번에는 멘토님들이 모든 멘티를 대면으로 관리할 수 없었기에 PR review가 빛을 발했다고 생각한다. 글을 통해 생각을 정리하여서 전달하니 내가 무엇을 몰랐으며 어떤 부분에서 어떻게 막혀서 이렇게 생각했고 시도했으나 실패했다는 과정을 담을 수 있었고 좀 더 효율적인 소통이 된 것 같았다. PR review의 순기능을 몸소 체험했다. 

 

이것으로 오픈소스 컨트리뷰션 아카데미의 첫 번째 과제를 끝냈다. 나중에 오픈소스 이슈를 직접 발굴하고 PR을 해결하기까지 아직 멀었지만 그때까지 계속 공부하면서 많은 성장을 이루어내자. 이번엔 GitHub 협업 배웠다.