gitlab workflow

요즘 Jenkins 재부팅 하는 주기가 늘어나고 있다. 이유는 Jenkins 메모리를 거의 Full로 사용한다는 것이고 그 중에 하나가 forked repo라고 한다. 솔직히 직접 들어가서 보진 않았고 이해는 가지 않았지만 다양한 이슈로 인해 Infra 팀에서 forked repo 사용을 지양해 달라고 요청이 왔다.

 

Forked repo를 지양해달라는 이유로는 다음과 같다

• Jenkins 에 부하가 많이 걸림 (Scan Issue)
• Gitlab 저장 공간 낭비
• Supplier간에 접근 제어 문제
• 유지 보수 문제 (forked repo의 configuration 문제로 자주 문의가 옴, 특히 등록 안된 사용자가 commit을 한 경우)

 

Gitlab CI/CD Concept

 

어제 gitlab company의 PM들과 현재 문제점에 대해서 미팅을 했다. 그리고 gitlab에서는 forked repo보다 원래 저장소에서 직접 branch를 만들고 거기서 fork를 하라고 추천을 했다. 하지만 거의 1000명 이상의 개발자가 있는 yocto layer에서 누가 어떻게 저장소에 push하고 이를 오용하여 사용할지 모르기 때문에 반대를 했다.

 

결국 대안으로 1개의 forked 저장소를 만들고 모든 개발은 거기서 해서 원본 저장소에 Merge Request를 날리는 것으로 정했다. 특별히 Pipeline을 새로 설정한 일도, 개발자들에게 많은 프로세스의 변화도 일으키지 않아서 첫 시도로는 괜찮을 것으로 보고 다들 동의했다.

 

한가지 주의해야할 점은 forked repo가 같은 group에 다른 이름으로 만들어지지 않는다. 그래서 그 그룹에 subgroup인 dev를 만들고 그곳에 원본 저장소를 fork 했다. 그냥 fork를 안하고 다른 이름의 저장소를 만들어 mirroring을 하면 fork가 원본 저장소로 안되는 문제가 발생한다.

 

이를 하면서 아래와 같이 설정을 하면 좋다.

• protected branch 에 대한 미러링 설정 - https://docs.gitlab.com/ee/user/project/repository/mirror/
• 주기적으로 업데이트 안되는 branch 삭제

다음주 월요일부터 공식적으로 적용하는데 어느 정도 혼란이 있는지, 그리고 기존 fork repo는 어떻게 지울지 고민을 해봐야겠다.