<div id="readability-page-1" class="page"><div><article><img src="https://get6.github.io/blog/external/8bc8381d0cb7811fdcdf1fdad8f72072.webp" alt="photo by Cristina Gottardi(https://unsplash.com/@cristina_gottardi?utm_source=templater_proxy&amp;utm_medium=referral) on Unsplash">
CI가 갑자기 전부 빨간불이 뜨면, 대부분 코드나 설정을 먼저 의심하잖아요. 그런데 이번에는 코드도, YAML도, runner도 아니었어요. 오늘은 개발 문제가 아니라 운영 문제에 가까운 삽질을 했거든요.
시작은 단순했어요. 우리 조직의 여러 private repo에서 GitHub Actions CI가 전부 실패하고 있었어요. 처음에는 self-hosted runner 문제라고 생각했죠. 최근에 로컬 Mac mini를 GitHub Actions runner로 붙였고, 여러 repo의 CI를 <code>self-hosted</code> runner로 돌리도록 바꿨거든요.
그런데 증상이 이상했어요.
보통 runner에 문제가 있으면 job이 만들어진 뒤에 <code>queued</code> 상태로 멈추거나, "matching runner가 없다"는 식으로 실패해요. 그런데 이번에는 job 자체가 없었어요.
대표 run 상태는 이랬어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">conclusion: startup_failure
workflowName: ""
path: BuildFailed
jobs: []
logs: 404</code></pre></figure>
로그도 없었어요. 정확히는 로그가 생기기 전에 죽은 거였죠.
<h2 id="처음-의심한-것-self-hosted-runner-설정">처음 의심한 것: self-hosted runner 설정<a href="#처음-의심한-것-self-hosted-runner-설정">#</a></h2>
가장 먼저 의심한 건 로컬 runner였어요.
실제로 과거 설정에는 문제가 있었거든요. runner가 기본 <code>_work</code> 폴더를 쓰고 있었고, 외장 SSD에 작업 디렉터리를 두려면 <code>--work</code> 옵션을 줘야 했어요.
현재는 아래처럼 고쳐져 있었어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">workFolder: /mnt/ssd/actions-work/my-org</code></pre></figure>
runner도 online 상태였고요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">runner: local-mac-mini
status: online
busy: false
labels:
- self-hosted
- macOS
- ARM64
- local
- mac-mini</code></pre></figure>
그런데도 문제가 계속됐어요.
그래서 <code>self-hosted</code> runner를 아예 쓰지 않는, 아주 단순한 smoke workflow도 만들어봤어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="yaml" data-theme="github-dark-dimmed"><code data-language="yaml" data-theme="github-dark-dimmed">name: Actions Smoke Test
 
on:
 push:
 branches:
 - test/actions-smoke
 workflow_dispatch:
 
jobs:
 smoke:
 runs-on: ubuntu-latest
 steps:
 - name: Print smoke marker
 run: echo "actions-smoke-ok"</code></pre></figure>
그런데 이것도 똑같이 실패했어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">conclusion: startup_failure
workflowName: ""
path: BuildFailed
jobs: []</code></pre></figure>
이 시점에서 runner만의 문제는 아니라고 봐야 했어요. <code>ubuntu-latest</code>도 runner에 도달하기 전에 죽었으니까요.
<h2 id="두-번째-의심-enterprise--organization-runner-group-꼬임">두 번째 의심: Enterprise / Organization runner group 꼬임<a href="#두-번째-의심-enterprise--organization-runner-group-꼬임">#</a></h2>
그다음에는 GitHub Enterprise 설정을 의심했어요.
최근 Enterprise 사용이 끝났는데, Organization 쪽 Actions runner group 화면에 이런 경고가 떠 있었거든요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">Runner group Default already exists at the Enterprise level.
Please consider renaming this group.</code></pre></figure>
이건 충분히 수상했어요.
organization에는 runner group <code>Default</code>가 있고, Enterprise level에도 <code>Default</code>가 남아 있는 것처럼 보였어요. 게다가 API로 보면 <code>Default</code> runner group이 두 개처럼 보였고요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">id 1: Default, visibility=all
id 3: Default, visibility=selected</code></pre></figure>
그래서 한동안은 "Enterprise가 끝났는데 runner group policy가 남아서 org Actions가 꼬인 것 아닌가?"라고 생각했어요.
이 가설도 나쁘진 않았어요. 실제로 Enterprise 종료 후 잔여 설정은 정리하는 게 맞고, runner group 이름도 <code>Default</code>보다는 <code>local-mac-mini</code> 같은 구분되는 이름으로 바꾸는 게 좋거든요.
하지만 이것도 결정적 원인은 아니었어요. 왜냐하면 private repo뿐 아니라, GitHub-hosted runner를 쓰는 smoke workflow까지 <code>BuildFailed</code>로 죽었기 때문이에요. runner group이 원인이라면 적어도 <code>ubuntu-latest</code> workflow는 다르게 실패해야 했거든요.
<h2 id="github-support-답변-billing-lock">GitHub Support 답변: billing lock<a href="#github-support-답변-billing-lock">#</a></h2>
결국 GitHub Support에 문의했어요. 답변은 의외로 간단했어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">The BuildFailed behavior occurs when an account's billing is locked,
blocking access to billable features, like Actions.</code></pre></figure>
즉 원인은 코드도, YAML도, runner도 아니었어요. billing lock 때문에 Actions 자체가 막힌 상태였던 거죠.
이 설명이면 모든 증상이 맞아떨어져요.
<ul>
<li>여러 private repo에서 동시에 실패</li>
<li><code>self-hosted</code> runner도 실패</li>
<li><code>ubuntu-latest</code>도 실패</li>
<li>job이 생성되지 않음</li>
<li>logs endpoint가 404</li>
<li>workflow name이 비어 있음</li>
<li><code>BuildFailed</code>라는 synthetic workflow가 생김</li>
</ul>
GitHub Actions는 private repo에서 billable feature(과금 대상 기능)로 취급돼요. billing account가 locked 상태면 runner 종류와 상관없이 workflow startup 단계에서 막힐 수 있는 거예요.
<h2 id="문제가-된-건-organization-계정이었어요">문제가 된 건 organization 계정이었어요<a href="#문제가-된-건-organization-계정이었어요">#</a></h2>
추가로 Support에 확인한 결과, 문제가 된 billing account는 개인 계정이 아니라 organization 계정이었어요.
이걸로 범위가 확정됐어요.
처음에는 개인 계정 문제일 수도, 종료된 Enterprise 문제일 수도, organization 문제일 수도 있었어요. 그런데 최종적으로는 organization의 billing lock이었죠.
Support는 billing team으로 새 티켓을 열어달라고 안내해줬어요.
<h2 id="이번에-배운-것">이번에 배운 것<a href="#이번에-배운-것">#</a></h2>
이번 삽질에서 얻은 교훈은 꽤 명확해요.
<h3 id="1-buildfailed--startup_failure--jobs는-runner-문제가-아닐-수-있어요">1. <code>BuildFailed</code> + <code>startup_failure</code> + <code>jobs=[]</code>는 runner 문제가 아닐 수 있어요<a href="#1-buildfailed--startup_failure--jobs는-runner-문제가-아닐-수-있어요">#</a></h3>
runner 문제라면 보통 job은 생겨요. 예를 들면 이런 형태가 되죠.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">queued
waiting for runner
no matching runner</code></pre></figure>
그런데 이번처럼:
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">workflowName: ""
path: BuildFailed
jobs: []
logs: 404</code></pre></figure>
이렇게 나온다면 workflow가 runner에 도달하기 전에 죽은 거예요. 이 경우 YAML, runner label, runner online 여부만 붙잡고 있으면 시간을 많이 낭비할 수 있어요.
<h3 id="2-private-repo-actions는-billing-상태의-영향을-받아요">2. private repo Actions는 billing 상태의 영향을 받아요<a href="#2-private-repo-actions는-billing-상태의-영향을-받아요">#</a></h3>
self-hosted runner를 써도 Actions 자체는 GitHub의 billable feature 영역에 걸려요. 그래서 "내 runner에서 도는데 왜 billing이 문제지?"라고 생각하면 안 돼요.
Actions orchestration(작업을 큐에 넣고 runner에 배정하는 과정) 자체가 GitHub feature이기 때문이에요.
<h3 id="3-enterprise-종료-후에는-billingaccount-scope를-꼭-확인해야-해요">3. Enterprise 종료 후에는 billing/account scope를 꼭 확인해야 해요<a href="#3-enterprise-종료-후에는-billingaccount-scope를-꼭-확인해야-해요">#</a></h3>
Enterprise를 종료했다고 해서 모든 잔여 상태가 깔끔히 사라지는 건 아닌 것 같아요. 적어도 이번에는 이 전부가 얽혀 있었거든요.
<ul>
<li>Enterprise 종료</li>
<li>Organization billing</li>
<li>Actions runner group</li>
<li>private repo Actions</li>
<li>Support ticket routing</li>
</ul>
Enterprise가 끝났다면 다음을 확인해보세요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">Personal billing
Organization billing
Enterprise billing
Actions access
Runner groups
Outstanding balance
Seats
Billing cycle</code></pre></figure>
특히 결제정보를 추가하기 전에 "얼마가 즉시 청구되는지" 확인하는 게 중요해요.
<h2 id="최종-정리">최종 정리<a href="#최종-정리">#</a></h2>
이번 문제의 root cause는 이렇게 정리할 수 있어요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="text" data-theme="github-dark-dimmed"><code data-language="text" data-theme="github-dark-dimmed">organization billing lock
→ GitHub Actions billable feature blocked
→ all private repo workflows fail at startup
→ synthetic BuildFailed workflow
→ jobs=[]
→ logs=404</code></pre></figure>
다음 액션은 runner를 다시 설치하는 게 아니라 billing team에 확인하는 거예요. 확인해야 할 핵심은 이 정도예요.
<ol>
<li>미납 잔액(outstanding balance)이 있는지, 있다면 정확한 금액은 얼마인지</li>
<li>결제정보를 추가하면 즉시 얼마가 청구되는지 (월결제 전환이 가능한지 포함)</li>
<li>종료된 Enterprise billing scope와 아직 연결돼 있는지</li>
</ol>
오늘의 결론은 이거예요. CI가 터졌다고 항상 코드나 runner 문제는 아니에요. 가끔은 결제 상태가 가장 낮은 레벨의 인프라 장애처럼 나타나거든요. 증상이 아무리 봐도 인프라 같은데 아무것도 안 잡힌다면, billing 상태도 한 번 열어보세요.
<hr>
<blockquote><div>When you have eliminated the impossible, whatever remains, however improbable, must be the truth.</div>— Arthur Conan Doyle</blockquote></article></div></div>

이때의 나

sunhwang

CI가 갑자기 전부 빨간불이 뜨면, 대부분 코드나 설정을 먼저 의심하잖아요. 그런데 이번에는 코드도, YAML도, runner도 아니었어요. 오늘은 개발 문제가 아니라 운영 문제에 가까운 삽질을 했거든요. 시작은 단순했어요. 우리 조직의 여러 private repo에서 GitHub Actions CI가 전부 실패하고 있었어요. 처음에는 self-hosted...

BuildFailed로 CI가 전부 터졌는데, 원인은 결제 잠금이었다

댓글