👋 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서버는 체크아웃 전까지 우리가 올려놓은 코드를 전혀 알..

들어각기 전 gitAction과 구조gitAction이란GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼이다. 구조Workflow하나 이상의 Job으로 구성된 실행할 가능한 자동화hamp.tistory.com 이전 포스팅에서 gitAction에 대해 알아보고 그 구조를 살펴봤다. 이번 포스팅에서는 그 구조를 만들어보며 다양한 키워드를 학습해보자.주의할 점YAML 파일은 들여쓸 때 공백 2번으로 들여쓰고, 만약 잘못된 indent로 작성할 경우 실행되지 오류가 발생한다.workflow 작성# testAction.ymlname: testWorkflow # workflow 이름을 적어준다.on: # 감지할 이벤트를 써준다. ..

gitAction이란GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼이다. 구조Workflow하나 이상의 Job으로 구성된 실행할 가능한 자동화된 프로세스YAML 파일에 정의되며 정의된 이벤트 트리거에 의해 실행된다. .github/workflows  디렉터리에 정의된다.EventWorkflow를 실행할 특정 규칙을 말한다.대표적으로 레포지토리에 푸쉬하거나 요청할 때와 같은 예를 들 수 있다.Job여러가지 Step으로 구성되며 단일 가상환경에서 실행된다.기본적으로는 종속성없이 병렬로 실행된다.하지만 작업간의 종속성을 설정하면 의존하는 작업은 앞 작업이 모두 성공적으로 끝내야 실행된다.StepJob 안에서 순차적으로 실행되..