공개 GitHub 저장소가 clone 인증을 요구할 때, CI는 어떻게 바꿀까?

공개 저장소도 인증을 요구할 수 있다

공개 GitHub 저장소가 HTTPS clone 도중 인증을 요구해도 비공개로 바뀌었다는 뜻은 아니다. GitHub는 10월 19일 공지에서 비정상 트래픽이 몰리는 동안 일부 익명 clone·fetch에 인증을 요구할 수 있다고 밝혔다. 영향을 받는 작업은 인증 후 다시 실행하거나, 보호 조치가 해제된 뒤 익명으로 재시도할 수 있다.

이미 인증한 HTTPS Git과 SSH Git, push, 관련 없는 웹·API 요청은 이 조치의 대상이 아니다. ‘공개 저장소를 받으려면 모두 로그인해야 한다’는 변경으로 읽으면 범위를 잘못 이해하게 된다.

무인 CI에서는 인증 요청이 사용자명 입력 실패로 나타날 수 있다. GitHub Community의 한 개발자는 공개 MariaDB 저장소를 받는 CI에서 terminal prompts disabled 오류가 간헐적으로 발생한다고 보고했다. 입력할 사람이 없는 작업에서는 인증을 미리 연결하는 일이 중요하다.

내 PC에서는 Git이 사용할 인증을 저장한다

GitHub CLI가 설치돼 있다면 공식 인증 저장 절차에 따라 gh auth login을 실행하고 Git 프로토콜로 HTTPS를 고른다. Git에도 해당 인증을 사용하겠느냐는 질문에 동의하면 이후 작업에서 인증값을 쓸 수 있다.

gh auth login
gh auth setup-git
git clone https://github.com/OWNER/REPOSITORY.git

위 예시는 로그인 뒤 gh auth setup-git으로 helper 연결을 명시하는 순서다. OWNER와 REPOSITORY는 실제 공개 저장소 이름으로 바꾼다. helper는 Git이 필요한 인증값을 gh에서 받게 하는 기능이며, 아직 로그인하지 않은 계정을 대신 인증하지는 않는다.

계정 비밀번호를 계속 바꾸는 방법은 맞지 않는다. GitHub의 HTTPS Git 인증은 계정 비밀번호 대신 개인 액세스 토큰이나 credential helper를 사용한다. Git Credential Manager를 쓰는 환경이라면 그 인증 경로를 이용할 수 있다.

CI는 토큰 보유보다 실제 clone에 전달되는지가 중요하다

GitHub Actions에서는 내장 GITHUB_TOKEN을 사용할 수 있다. actions/checkout의 기본 token 값은 이 토큰을 가리키며, 문서는 일반적인 checkout에 contents: read 권한을 권장한다. 이미 이를 쓰는 단계와, 별도 shell 스크립트에서 익명으로 실행하는 git clone을 나눠 살펴봐야 한다.

GITHUB_TOKEN은 작업마다 발급되고 권한이 해당 저장소로 제한된다. 다른 비공개 저장소까지 가져오는 작업에는 그 저장소에 접근할 별도 인증이 필요하다. 토큰을 환경변수에 넣었다는 사실만으로 모든 Git 프로세스의 인증이 끝났다고 볼 수는 없다. 사용 중인 checkout이나 helper가 그 값을 읽는 연결이 있어야 한다.

새 보호 조치만으로 모든 인증 실패를 설명할 수는 없다

인증을 연결한 뒤에도 실패하면 공식 clone 오류 안내대로 URL 철자와 계정의 접근 권한, 캐시에 남은 인증값을 확인한다. 오래되거나 잘못 저장된 자격증명도 실패 원인이 된다. SSH 키를 이미 구성한 환경은 SSH 주소로 접근할 수 있지만, 주소만 바꾸는 것으로 키 설정까지 끝나지는 않는다.

어느 단계에서 어떤 인증 방식으로 실패했는지부터 확인해야 한다. 공개 저장소를 익명으로 받던 CI인지, 유효한 토큰을 쓰던 작업인지에 따라 조사할 곳이 달라진다. 무인 clone을 계속 운영하려면 실제 Git 요청까지 이어지는 인증 경로를 갖추고, 재시도 결과를 확인해야 한다.