Step과 Job의 차이점 Step은 무조건 순차적으로 실행되는 반면, Job은 병렬적으로 실행될 수도 있고 순서대로 실행될 수도 있다. 이 말은 Step에서 실패를 제어하기 위해 사용했던 전제인 "먼저 실행된 Step은 이후 Step 시작 전에 끝난다"가 더이상 유효하지 않다는 뜻이다. 따라서 이 전제를 맞추기 위해 추가적인 설정을 해주어야 한다. 병렬적인 Job 간의 실패 제어 일단, 병렬적인 Job A와 Job B가 있다고 해보자. B가 A의 실패를 제어하는 것은 불가능하다. 이유는 B는 A에 대한 정보가 없기 때문이다. 하나의 Job이 다른 Job에 대한 정보를 알기 위해서는 needs Context를 사용해야 하는데, 병렬적인 Job 간에는 needs에 다른 Job의 정보가 없다. 공식 문서에는..
CI, CD/GitHub Actions
Step 실패 시 흐름 제어 이전 글에서 if와 failure() 을 조합해 Step 실패 시 실행되는 Step을 정의해보았다. 그렇다면 만약 여러 Step이 있고 특정 Step이 fail 되었을 때만 수행되어야 하는 Step이 있으면 어떻게 해야할까? 바로 if 문에 step failure을 체크하기 위한 코드를 추가하는 것이다. 이를 위해 다른 step의 어떤 상태 값에 접근할 수 있는지 Context를 확인해보자. 특정 step이 fail 되었는지 체크하기 위한 Context steps Context 에서는 steps..outcome 를 통해 step 실행 결과에 대한 상태 값을 제공한다. 속성 이름 Type Description steps..outcome string continue-on-erro..
Step의 Fail을 제어하는 것이 필요한 이유 테스트를 돌렸는데 테스트가 Fail 되었을 때 Test 리포트를 업로드 하는 Step이 수행되어야 하는데 수행되지 않는다면 어떻게 될까? 테스트를 돌린 것 자체가 의미가 없어진다. 테스트가 Fail 되면 Test 리포트가 업로드 되어야 한다. 즉, 특정한 Step이 Fail 되더라도 다른 Step이 진행되어야 할 수 있다. Job을 만들다 보면 위와 같은 상황을 자주 마주한다. 이번 글에서는 위 상황을 제어하는 방법에 대해 알아본다. 먼저 문제 상황을 만들어보자 문제 상황 만들기 이번 글에서 다룬 문제 상황은 바로 안드로이드에서 테스트를 돌렸는데 실패하는 경우이다. Workflow 파일 만들기 app 모듈에 대해 testDebug Task를 실행하고 테스트..
환경 별로 다른 값을 전달하는 것이 중요한 이유 환경 별로 다른 값이 필요한 이유는 환경 별로 아이디/비밀번호 혹은 DB 이름 등이 다를 수 있기 때문이다. 실제로 많은 앱들은 테스트용 환경과 릴리즈 환경을 나누어 놓는데 이는 보안에 매우 중요하다. 이 문제를 해결하기 위해 GitHub Actions는 같은 Key로 Secrets에 접근한다고 하더라도 환경 별로 다른 값을 전달할 수 있는 기능을 제공한다. 이 글에서는 바로 환경 별로 다른 Secrets 를 전달하는 방법에 알아볼 것이다. 환경별로 다른 Secrets 생성하기 환경 별로 다른 Secrets를 생성하기 위해서는 GitHub의 Environment 기능을 설정해야 한다. Environment는 Settings-Environments 에 위치한..
보안이 필요한 변수와 Environment Variable 앞선 글에서 Environment Variable을 사용해 변수에 값을 저장하는 방법에 대해 배웠다. 하지만 Environment Variable을 사용해 DB이름이나 계정의 비밀번호 혹은 토큰을 저장하게 되면 보안에 문제가 생길 수 있다. 이를 해결하기 위해 쓰는 것이 바로 Secrets이다. Secrets는 Environment Variable과 비슷하게 동작하지만, 외부로 공개되지 않는 Key-Value 쌍이다. 따라서 토큰이나 비밀번호 같은 보안이 필요한 정보들은 Secrets를 통해 저장해야 한다. 자 Secrets를 설정하는 방법에 대해 알아보자. Secrets 설정하기 1. Settings -Secrets - Actions 에 진입한..
