GitHub Pages 사용자 사이트 내리기

커스텀 도메인을 연결해 둔 GitHub Pages 사용자 사이트(<user>.github.io 저장소)를 내리는 과정에서 확인한 동작을 정리합니다. 사이트는 gh-pages 브랜치에서 빌드되는 구성이었고, 저장소는 남겨 두고 사이트만 내리는 것이 목표였습니다.

먼저 DNS 레코드 정리

커스텀 도메인이 GitHub Pages를 가리키는 레코드부터 삭제합니다.

Pages를 끈 뒤에도 이 레코드가 남아 있으면, 다른 계정이 같은 도메인을 자기 Pages에 연결할 수 있는 상태가 됩니다. GitHub의 도메인 소유 확인(verified domain)을 해 두지 않았다면 레코드를 먼저 지우는 편이 안전합니다.

API로는 끌 수 없음

Pages를 끄는 API는 DELETE /repos/{owner}/{repo}/pages입니다. 사용자 사이트 저장소에 이 요청을 보내면 다음 응답이 돌아옵니다.

gh api -X DELETE repos/<user>/<user>.github.io/pages
# HTTP 422: Deactivating GitHub pages for this repository is not allowed.

저장소 이름을 바꿔 프로젝트 사이트로 만든 뒤에도 같은 422 응답이 돌아왔습니다. 응답에 이유는 나오지 않으며, 이 저장소에서는 API로 Pages를 끄는 방법이 없었습니다.

비공개 전환으로는 내려가지 않음

저장소를 비공개로 바꿔도 사이트는 계속 공개됩니다. GitHub Pro 이상 요금제에서는 비공개 저장소도 Pages를 공개로 서비스하기 때문입니다.

• GET /repos/{owner}/{repo}/pages 응답의 "public": true 유지
• 설정 화면 안내: “This repository is private but the published site will be public.”

무료 요금제에서는 비공개 저장소의 Pages가 지원되지 않으므로 결과가 다를 수 있습니다.

소스 브랜치를 바꾸면 커스텀 도메인이 돌아옴

커스텀 도메인은 PUT /repos/{owner}/{repo}/pages에 cname=null을 보내 해제할 수 있습니다. 그런데 이후 소스 브랜치를 다른 브랜치로 바꾸면, 그 브랜치 루트의 CNAME 파일 내용으로 커스텀 도메인이 다시 설정됩니다.

gh api -X PUT repos/<user>/<repo>/pages -F cname=null          # cname: null
gh api -X PUT repos/<user>/<repo>/pages -f 'source[branch]=master'
gh api repos/<user>/<repo>/pages -q .cname                     # example.dev

예전 구성의 CNAME 파일이 여러 브랜치에 남아 있다면 소스 브랜치를 바꿀 때마다 확인이 필요합니다.

설정 화면에서 내리기

최종적으로는 저장소 설정 화면에서 두 단계로 내렸습니다.

1. Settings › Pages › Unpublish site 실행
   • 확인 창 안내: “Unpublishing will remove this GitHub Pages site and prevent it from being served, but it will not prevent it from being rebuilt.”
2. Build and deployment › Branch를 None으로 바꾼 뒤 저장
   • 1단계만 하면 소스 브랜치에 푸시가 있을 때 다시 빌드될 수 있음

두 단계 이후 GET /repos/{owner}/{repo}/pages는 404를 돌려줍니다. 이번에는 저장소 이름을 바꾼 뒤 진행했기 때문에, 사용자 사이트 이름 그대로에서도 같은 버튼이 동작하는지는 확인하지 않았습니다.

캐시가 빠지는 시간

Pages를 끈 직후에도 <user>.github.io는 한동안 200과 예전 내용을 돌려줍니다. 응답 헤더 기준으로는 CDN 캐시입니다.

이번에는 Unpublish 후 약 10분 뒤에 404로 바뀌었습니다.

정리