나는 GitHub Actions이 정말 싫어요

• GitHub Actions의 느린 피드백 루프와 복잡한 디버깅 과정에 대한 개발자의 좌절 경험 공유
• tmplr 프로젝트에서 build.rs를 통해 CUE로 문서를 생성했으나, CI 빌드가 실패하면서 문제 시작
• 4개 플랫폼 중 Linux ARM만 빌드 실패, 원인은 cross build 시 x86_64 바이너리가 arm64 러너에서 숨겨지는 GitHub Actions의 동작 방식
• 단일 변경 사항 테스트에 2~3분이 소요되는 비효율적인 피드백 루프 반복
• 해결책으로 build.rs를 삭제하고 GNU Makefile로 전환, CI 로직을 직접 제어하는 방식으로 문제 해결

문제 발생 배경

• tmplr은 사람이 읽고 작성할 수 있는 템플릿 파일을 사용하는 파일/프로젝트 스캐폴딩 도구
• build.rs에서 CUE를 사용해 README.md, CHANGELOG.md, 버전/도움말 파일을 생성하여 일관성 보장
• 작업 자체는 약 1.5시간 만에 완료되었고, 관련 글도 작성완료
• 로컬에서는 정상 작동했으나, GitHub Actions의 CI 환경에서 CUE 바이너리 미설치로 빌드 실패

빌드 실패 원인

• 4개 플랫폼(Linux ARM, macOS ARM, Linux x86_64, macOS x86_64) 중 Linux ARM만 “command not found” 오류 발생
• 원인: matrix cross build가 강하게 격리되어, CUE는 x86_64 Linux 호스트와 macOS ARM 호스트에만 설치됨
  • macOS는 x86_64 바이너리 실행에 문제없음
  • Linux x86_64도 x86_64 바이너리 실행에 문제없음
  • 그러나 GitHub Actions는 arm64 러너에서 x86_64 바이너리를 숨겨 실행 불가 상태로 만듦

비효율적인 피드백 루프

• 문제 해결을 위해 반복한 과정:
  1. 가능한 수정 방법 검색
  2. ci.yml 변경
  3. 커밋 및 푸시 (jj squash --ignore-immutable && jj git push)
  4. "Actions" 탭 열기
  5. 최신 실행 열기
  6. Linux ARM 실행 열기
  7. 몇 초 대기
  8. 좌절
  9. 반복
• 단일 변경 사항당 2~3분 소요
• 이상적으로는 GitHub가 모든 기능을 갖춘 로컬 러너를 제공하거나, 또는 푸시 후 빠르게 진행 상황을 확인할 수 있는 기능을 제공 가능
  • "scratch commit" 같은 기능: Git 히스토리와 Action 실행 기록을 오염시키지 않고 다양한 실행을 테스트할 수 있는 방법
• 그러나 현재 그런 기능은 존재하지 않음

해결 방법

• 30분간 루프를 반복한 후 중단
• 인터넷에서 알려진 방법 적용: "GitHub Actions가 로직을 관리하게 하지 말고, 스크립트를 직접 제어하고 Actions는 그 스크립트를 호출만 하게 할 것"
• build.rs 삭제 (아쉬움이 있었으나 희생 필요)
• 모든 생성 작업을 GNU Makefile로 이동
• 생성된 파일들을 저장소에 커밋하고, CI 변경 사항 되돌림
• 문제 해결 완료

결론

• GitHub Actions는 일부 좋은 것들을 가질 수 없게 만드는 원인임
• 러너 디버깅이나 빌드 프로세스 최적화에 많은 시간 손실
• 그러나 다른 방법으로는 얻기 어려운 macOS 빌드 같은 이점도 존재함
• 물론, GitHub Actions보다 설정하기 쉬운 다른 시스템은 알려지지 않음

We are all doomed to GitHub Actions. …but at least I dodged the bullet early.