셀프 호스팅 러너가 어느 날 등록되지 않거나 작업 실행이 막히면, 대개 워크플로 YAML부터 보게 된다. 하지만 러너 애플리케이션 버전의 지원 종료가 원인이라면 YAML을 고쳐도 해결되지 않는다. GitHub가 2026년 9월 3일에 runner 버전의 등록·실행 지원 종료 시점을 돌려주는 REST API를 추가했다. 이제 종료 공지를 사람이 찾아 읽는 대신, 운영 중인 버전을 CI 점검 항목에 넣을 수 있다.
이번 업데이트에는 GITHUB_TOKEN의 Dependabot 경고 읽기 권한과 재사용 워크플로의 원본 정보를 알려 주는 job 컨텍스트도 함께 들어왔다. 셀프 호스팅 러너나 공용 재사용 워크플로를 운영한다면 세 가지를 한 번에 확인해 둘 만하다. 변경 사항의 원문은 GitHub Actions 9월 업데이트 공지에서 볼 수 있다.
러너 지원 종료를 API로 확인하기
새 엔드포인트는 저장소, 조직, 엔터프라이즈 범위에서 GET /actions/runners/deprecations/{version}으로 호출한다. 응답에는 확인한 runner_version과 runtime_deprecates_at, registration_deprecates_at가 들어온다. 즉 이미 등록한 러너가 실행 가능한 마지막 시점과, 새 러너 등록이 가능한 마지막 시점을 분리해서 볼 수 있다.
실제 운영에서는 우선 각 러너의 버전을 인벤토리로 모은 뒤, 그 버전마다 이 API를 조회하면 된다. 날짜가 가까운 버전은 바로 업데이트 작업으로 넘기고, 지원 기간이 남은 버전은 다음 정기 점검까지 보류한다. API의 정확한 범위와 응답 필드는 GitHub의 변경 공지를 기준으로 확인하는 편이 안전하다.
예: gh api -H “X-GitHub-Api-Version: 2026-03-10” /repos/OWNER/REPO/actions/runners/deprecations/RUNNER_VERSION
이 호출은 러너를 바꾸지 않는다. 그래서 먼저 cron이나 별도 점검 워크플로에서 결과를 수집하고, 지원 종료가 임박했을 때만 이슈나 알림을 만드는 방식이 부담이 적다. GitHub REST API 문서는 hosted runner 관련 엔드포인트에서 토큰 종류와 조직 권한 모델을 설명한다. GitHub-hosted runners REST API 문서도 같이 보는 이유다.
Dependabot 경고만 읽게 하기
워크플로가 Dependabot alerts를 읽어야 하는데 기존 권한을 넓게 준 경우가 있다. 이번에 vulnerability-alerts가 read와 none 값으로 추가됐다. 필요한 작업에만 contents: read와 vulnerability-alerts: read를 넣으면 된다.
permissions에서 하나라도 명시하면, 명시하지 않은 권한은 none이 된다. 따라서 기존 워크플로에 이 블록을 추가할 때는 이미 필요했던 contents, pull-requests, security-events 권한까지 빠지지 않았는지 확인해야 한다. GitHub의 workflow syntax 문서는 이 동작과 vulnerability-alerts: read|none 값을 명시한다.
권한을 줄였다고 해서 경고를 자동으로 고치는 것은 아니다. 이 권한은 읽기 전용이다. 조회·리포트 용도라면 충분하지만, 이슈 생성이나 PR 생성까지 하는 워크플로라면 그 작업에 맞는 별도 최소 권한을 추가해야 한다.
재사용 워크플로가 자기 원본을 찾을 수 있다
공용 저장소의 reusable workflow 안에서 github.workflow_ref를 찍어 보면, 호출한 쪽의 워크플로 정보가 나와서 헷갈리는 경우가 있다. 새 job.workflow_ref, job.workflow_sha, job.workflow_repository, job.workflow_file_path는 현재 job을 정의한 워크플로 쪽을 가리킨다.
예를 들어 공용 배포 워크플로와 같은 저장소에 스크립트를 함께 두었다면, 호출자 저장소가 아니라 워크플로 원본의 특정 커밋을 체크아웃할 수 있다. 이 값들은 GitHub Enterprise Server에서는 제공되지 않는다. 또한 직접 정의한 job에서는 기존 github.workflow_ref와 새 job.workflow_ref가 같고, reusable workflow일 때만 차이가 드러난다. GitHub Actions contexts 문서는 네 값의 의미와 이 체크아웃 예시를 제공한다.
이번 변경에서 바로 해 둘 일은 크지 않다. 셀프 호스팅 러너 버전 목록을 확보하고, 공용 워크플로에서 원본 파일을 참조하는 부분이 있는지 찾고, Dependabot 경고 조회 작업의 권한을 좁히면 된다. 지원 종료일을 감으로 관리하던 부분이 API 응답 하나로 바뀐 것이 가장 실용적이다.