👋 CI를 도입한 이유Tuist를 도입하여 우리는 각자 독립된 환경에서 필요한 부분만 빌드하는 이점을 살려개발의 생산성을 높혀 나가고 있었다. 그런데 여기서 예상치 못한 변수가 등장했다.. 바로 빌드되는 부분을 제외한 곳의 디버깅이 안되는 상황이다.현재 BaseFeature의 타겟을 빌드하게 되면 다른 타겟쪽은 빌드가 돌아가지 않기 때문에 컴파일 에러를 잡아낼 수 없다.그렇게되면 우리의 규칙인 pr단위는 반드시 빌드가 되야한다라는 규칙이 깨지게된다.  실제로 ci 도입 전 많은 pr은 굉장히 안전하지 않아고 실제로 pull을 받았을 때 빌드가 안되는 문제가 많았다. 이제부터 ci를 통해 범인 찾기와 범인 발생 자체를 최대한 막아보려고 한다. ⏰ 언제 검사할까?? 가장 먼저 고민해야할 부분은 action..

들어가기 전이전 시간에 우리는 workflow 구조에 다양한 키워드를 살펴봤다.거기서 uses 키워드를 이용해 이미 만들어진 것을 이용할 때 유용한 Marketplace action들을 모아 놓으면 추후 workflow를 만들 때 많은 도움이 될 것 같다.1. checkout첫번 째 action은 바로 workflow 제작 시 반드시 필요한 내용인 checkout action이다. 공식문서 Checkout - GitHub MarketplaceCheckout a Git repository at a particular versiongithub.com사용 목적코드 저장소에 올려둔 코드를 CI서버로 내려받은 후, 특정 브랜치로 전환하는 행위 실제로 우리 CI서버는 체크아웃 전까지 우리가 올려놓은 코드를 전혀 알..