태그나 브랜치가 다른 커밋으로 옮겨져도 워크플로는 잠금 파일에 기록된 커밋만 실행하고, 액션이 다시 쓰는 하위 액션과 재사용 워크플로까지 고정해요. 잠금 파일은 GitHub CLI 확장 gh actions-lock 으로 만들고 --verify 로 CI 에서 파일을 고치지 않고 최신 여부만 검사할 수 있으며, 등록한 워크플로에서는 디펜더봇이 버전 올림 PR 에 잠금 항목도 함께 갱신해요. 관리자는 유효한 잠금 파일이 없는 실행을 막는 'Require lockfile' 정책을 걸 수 있지만, 깃허브는 고정이 액션 자체의 안전성을 판단해 주지 않으니 잠그기 전에 검토하라고 적었고, 재사용 워크플로 호출의 하위 의존성은 고정 대상에서 빠지며 엔터프라이즈 서버는 지원하지 않아요.
용어 풀이
- CLI
- 명령줄로 쓰는 도구
- CI
- 코드를 올릴 때마다 자동으로 빌드·검사하는 과정
- PR
- 풀 리퀘스트, 코드 변경을 합쳐 달라는 요청
운영자 인사이트
공지에 AI 얘기는 없지만, 에이전트에게 워크플로 수정을 맡기는 저장소라면 영향이 있어요. 등록된 워크플로에 에이전트가 새 uses 를 넣고 잠금 파일을 갱신하지 않으면 실행이 막힐 수 있으니, 에이전트 지침에 gh actions-lock 실행과 --verify 확인을 넣어 두고 에이전트가 고른 새 액션은 잠그기 전에 사람이 검토하세요.
여러 관점으로 보기
- 공식 문서 잠금 파일은 손으로 고치지 않고, 재사용 워크플로는 그 워크플로가 정의된 저장소의 잠금 파일이 고정한다고 적었어요. GitHub Docs
- 도구 저장소 MIT 라이선스의 1.0 이전 미리보기라 형식과 옵션이 예고 없이 바뀔 수 있고, ./ 로 가리키는 로컬 액션을 쓰는 워크플로는 아직 등록에서 건너뛴다고 밝혔어요. GitHub