Step과 Job의 차이점 Step은 무조건 순차적으로 실행되는 반면, Job은 병렬적으로 실행될 수도 있고 순서대로 실행될 수도 있다. 이 말은 Step에서 실패를 제어하기 위해 사용했던 전제인 "먼저 실행된 Step은 이후 Step 시작 전에 끝난다"가 더이상 유효하지 않다는 뜻이다. 따라서 이 전제를 맞추기 위해 추가적인 설정을 해주어야 한다. 병렬적인 Job 간의 실패 제어 일단, 병렬적인 Job A와 Job B가 있다고 해보자. B가 A의 실패를 제어하는 것은 불가능하다. 이유는 B는 A에 대한 정보가 없기 때문이다. 하나의 Job이 다른 Job에 대한 정보를 알기 위해서는 needs Context를 사용해야 하는데, 병렬적인 Job 간에는 needs에 다른 Job의 정보가 없다. 공식 문서에는..
Job
Step의 Fail을 제어하는 것이 필요한 이유 테스트를 돌렸는데 테스트가 Fail 되었을 때 Test 리포트를 업로드 하는 Step이 수행되어야 하는데 수행되지 않는다면 어떻게 될까? 테스트를 돌린 것 자체가 의미가 없어진다. 테스트가 Fail 되면 Test 리포트가 업로드 되어야 한다. 즉, 특정한 Step이 Fail 되더라도 다른 Step이 진행되어야 할 수 있다. Job을 만들다 보면 위와 같은 상황을 자주 마주한다. 이번 글에서는 위 상황을 제어하는 방법에 대해 알아본다. 먼저 문제 상황을 만들어보자 문제 상황 만들기 이번 글에서 다룬 문제 상황은 바로 안드로이드에서 테스트를 돌렸는데 실패하는 경우이다. Workflow 파일 만들기 app 모듈에 대해 testDebug Task를 실행하고 테스트..
서로 다른 가상 머신에서 동작하는 Job build Job을 통해 ubuntu-latest 머신에 저장된 파일들은 다른 Job에서 접근이 불가능하다. 같은 이름의 머신이더라도 실제는 다른 가상 머신에서 돌아가기 때문이다. 따라서 build Job 다음에 실행되는 deploy Job을 추가한 다음 위에서 Apk를 Job Artifact로 만드는데 사용한 Path를 제공한다면 접근할 수 없다. 한 번 시도해 보자. 먼저 빌드를 하는 Job을 만든다. build: runs-on: ubuntu-latest steps: - name: Check out Repository uses: actions/checkout@v3 - name: set up JDK 11 uses: actions/setup-java@v3 with..
이전까지 내용 요약 이전까지 name:을 사용해 Work Flow의 이름을 정하고, on:을 사용해 Work Flow의 Trigger Event를 설정했으며, jobs: 에 first-job이라 불리는 첫 Job을 설정하고 이 Job의 runs-on: 에 ubuntu-latest를 설정해 GitHub Action에서 제공하는 가장 최신 우분투 버전에서 실행되도록 만들었다. # WorkFlow의 이름 설정 name: First Action # on: Work Flow가 언제 실행되어야 하는지 설정 # workflow_dispatch : 유저가 직접 실행하도록 설정하는 옵션 on: workflow_dispatch #jobs: workflow에 포함된 job들을 정의 jobs: #[Job 이름]: 으로 Job..
LaunchedEffect에서 한 번만 실행되어야 하는 동작 처리하기 LaunchedEffect는 key값이 바뀌면 블록내의 동작을 취소한 후 다시 실행한다. 따라서 한 번만 수행해야하는 작업들은 LaunchedEffect에 true나 Unit을 넘겨주는 방향으로 실행해야 한다. @Composable fun KotlinWorldScreen(oneTimeEffect: () -> String) { LaunchedEffect(true) { oneTimeEffect() } } 이렇게 하면 oneTimeEffect()는 한 번만 수행된다. LaunchedEffect에서 한 번만 실행되어야 하는데 동작이 길 때 처리하기 LaunchedEffect에서 긴 동작의 람다식을 처리해야 할 때는 rememberUpdated..
