내가 관리하는 프로젝트는 C로 만들어져 있고,
Windows 32bit, 64 bit에 Static, Shared 형태의 출력 그리고 Linux 32bit, 64bit에 Static, Shared 형태의 출력 또 OSX Universal에 Static, Shared 형태의 출력 또또또 Anrdoid Static, iOS Static 을 포함해
총 12개의 패키지를 만들어낸다.
jenkins에서 gitlab으로 이전 시켜 ci를 구축을 마치고 났는데, 시원섭섭하다.
이 성공적인 파이프라인 결과를 볼려고 얼마나 고생했나봤더니, 현재 파이프라인이 294번 그렇다 설정을 고치고 테스트를 반복한 횟수이다.
내가 부족해서 그렇기는 할테지만, 하나의 핑계 겸 팁을 하나 공유한다.
gitlab ci는 .gitlab-ci.yml을 읽어서 동작하는데, 포함 구조를 사용 할 수 있고, stage와 job이 있는데
내 경우 .gitlab-ci.yml에는 공통 부분을 넣고 각 플랫폼에 맞는 job을 구현한 .gitlab-ci_windows.yml 등을 포함하게 한 구조이다.
이 yml을 얼마나 작성하는지가 관건인데, 실수가 많이 들어가는 부분이다.
구조 짤 때까지만해도 좋았는데, git에 커밋하고 태깅하면서 yml이 동작하는 것을 보니 간단한 실수를해도 확인하기까지 시간이 많이 지난다.
그래서 gitlab ci locally build 등의 문장으로 검색하여 방법을 찾아봤는데 있었다.
이미 설정한 gitlab-runner에 그런 기능이 존재하고 있음을 확인하고 도전했지만 바로 실패했다.
이유는 gitlab-runner의 기능 부족인지 포함되는 파일에 있는 job을 인식 못하는 문제였다.
갑자기 .gitlab-ci.yml의 구조를 바꾸기가 난감해서 결국 가능 시간이 오래걸리는 방식으로 시험하느라 파이프라인이 이렇게... ㅠㅠ
여튼 새로 구조를 만드실 분이라면, 가능하면 job은 .gitlab-ci.yml에 넣어 쓰는 것을 추천 드린다는 것.
gitlab-runner가 더 잘 구현되면 좋겠지만, 현재는 안됨 ㅠ (이럴때 코드공헌을 해야하는데... 말만 이러고 있네..)
여튼 조만간 시간내서, ci 설정하는 과정 들을 정리 해야겠다.