허깅페이스, 깃허브 액션 CI를 자사 잡으로 옮겨 CPU 테스트 30% 단축

허깅페이스가 깃허브 액션(GitHub Actions) 기반 CI를 자사 서버리스 인프라인 허깅페이스 잡(Hugging Face Jobs)에서 실행하는 방법을 블로그로 공개했다. 실험 대상이던 오픈소스 프로젝트 트랙키오(Trackio)는 이 방식으로 CI를 옮긴 뒤 실시간 로그를 받아보면서 CPU 작업의 CI 시간을 약 30% 줄였고, GPU 머신에서 도는 새 테스트 묶음까지 추가했다.

기본값인 runs-on: ubuntu-latest는 편리하지만 한계도 있다. 깃허브 액션은 점검으로 느려지거나 멈출 수 있고, 제공되는 머신이 범용이라 GPU 접근이 어렵다. 트랙키오는 단위 테스트와 프런트엔드 검사용 안정적인 CPU CI와, 실제 CUDA 하드웨어가 필요한 GPU CI를 모두 원했다.

허깅페이스 잡은 t4-small이나 h200 같은 거의 모든 하드웨어 사양에서 명령이나 스크립트를 실행할 수 있는 서버리스 서비스다. 예컨대 hf jobs run python:3.12 형태로 파이썬 명령을 바로 돌릴 수 있다. CI 작업은 이미 명령 기반이고 깨끗한 환경에서 실행되며 적절한 하드웨어를 고르면 이점이 커, 잡과 잘 맞는다.

핵심은 깃허브 액션과 잡을 잇는 부분이다. 허깅페이스는 깃허브 액션 작업을 허깅페이스 잡 안에서 도는 일회성 자체 호스팅 러너로 바꿔주는 작은 다리 jobs-actions를 만들었다. hf-jobs-cpu-upgrade나 hf-jobs-t4-small 같은 라벨이 쓰이면 깃허브가 서명된 workflow_job 큐 웹훅을 깃허브 앱을 통해 디스패처로 보내고, 디스패처는 짧은 수명의 러너 등록 토큰을 발급해 해당 하드웨어에서 잡을 시작한다. 깃허브 입장에서는 그저 자체 호스팅 러너로 보인다.

설정 1단계는 디스패처다. 디스패처는 깃허브 웹훅을 받아 잡을 띄우는 작은 도커 스페이스로, huggingface/jobs-actions-dispatcher를 복제해 만든다. 실제 CI에서는 스페이스가 비활성 후 잠들어 웹훅을 놓치는 일이 없도록 cpu-upgrade 사양을 권장한다. 빌드가 끝나면 다음 단계에 필요한 깃허브 앱 웹훅 URL이 표시된다.

2단계는 깃허브 앱 생성과 설치다. 이 앱은 큐에 쌓인 워크플로 작업을 수신하고 일회성 러너 등록 토큰을 만들 권한이 필요하다. 잡 실행 권한이 있는 허깅페이스 토큰을 HF_TOKEN 시크릿으로 스페이스에 저장해야 하며, 이 계정이나 조직 기준으로 잡 비용이 청구된다. 트랙키오는 이 앱을 gradio-app/trackio 저장소에 설치했다.

실제 워크플로 변경은 단 한 줄이다. runs-on: ubuntu-latest 대신 runs-on: hf-jobs-cpu-upgrade를, GPU 테스트에는 runs-on: hf-jobs-t4-small을 쓰면 된다. 기존 깃허브 액션을 허깅페이스 잡에서 돌리는 데 이 한 줄 교체로 충분하다.

도커 이미지 선택 팁도 덧붙였다. 처음엔 ubuntu:22.04를 쓰고 매 실행마다 빠진 시스템 패키지를 설치했는데, 깃허브의 ubuntu-latest 이미지가 기본 제공하는 개발 도구가 없어 더 느렸다. 트랙키오 UI 테스트는 Playwright 브라우저, Node, ffmpeg, sqlite, git 등이 필요해, 어떤 도커 이미지든 쓸 수 있는 허깅페이스 잡의 특성을 살려 마이크로소프트 Playwright 이미지(mcr.microsoft.com/playwright:v1.60.0-jammy)로 바꿔 잘 작동했다.