GiitHub Actions의 작업 프로세스 실행 ≈ 작업 실행 시간을 합하지 못하면

"Google Data Portal을 통해 GiitHub Actions 일정 실행 후 대기 시간 시각화"에서 수행되는 워크플로우는 30분마다 일정을 수행합니다.따라서 서비스 장애의 영향을 받는 경우가 있습니다.그중에 몇 가지 재미있는 현상이 있는데, 예를 들면 필기 같은 것이다.

한 퀘스트 시간 10분 초과

위에서 수행한 각 워크플로우의 작업은 단 하나이며 작업 설정은 10분의 시간 초과입니다.

jobs:
  append:
    environment: append

    permissions:
      contents: 'read'
      id-token: 'write'

    runs-on: ubuntu-latest
    timeout-minutes: 10

그러나 작업 프로세스의 실행 시간도 20분을 초과할 수 있다

기릿허브가 고장 난 인근 일이었지만 작업 흐름이 시작돼 끝날 때까지 20분이 넘었다.
조사를 해보면'수초 동안 작업을 마쳤지만 작업 절차의 집행 시간이 길다'는 것을 알 수 있다.
▶ 그림 2-1 워크플로우 및 작업 수행 시간

일지를 다시 한 번 확인하면'런너가 임무를 받기 위해 기다리는 시간'이 길다는 것을 알 수 있다.
▶ 그림 2-2 러너 온라인 대기 시간

2022-03-18T01:50:37.2662072Z Requested labels: ubuntu-latest
2022-03-18T01:50:37.2662156Z Job defined at: hankei6km/gha-now-to-sheet/.github/workflows/append-00-13.yaml@refs/heads/main
2022-03-18T01:50:37.2662198Z Waiting for a runner to pick up this job...
2022-03-18T01:50:37.5434531Z Job is waiting for a hosted runner to come online.
2022-03-18T02:11:48.4331373Z Job is about to start running on the hosted runner: Hosted Agent (hosted)
2022-03-18T02:11:50.8795737Z Current runner version: '2.288.1'

비용이 들기 때문에 머릿속에서'일의 집행 시간=업무 절차의 집행 시간'을 이해했지만 이렇게 큰 차이는 의외였다.

끝말

이 같은 일은 비정규적인 일로 여겨지지만 평소에는 전혀 일어나지 않는다고 할 수도 없다.고장이 나지 않았을 때도 5분 가까이 나를 데리러 올 것이다[1].
"작업에 시간 초과를 설정했기 때문에 작업 흐름의 집행 시간이 일정한 범위 내에 있을 수 있다"고 전제한 전제에서 의도치 못한 함정이 있을 수 있다.
각주
실제 상황은 모르지만 GitHub Status - Incident History는 기록이 없는 상태다.↩︎