워크플로 종속성 락파일

잠금 파일은 워크플로가 의존하는 모든 작업을 확인된 커밋에 고정하므로 검토한 코드가 바로 실행되는 코드입니다.

이 기사에서

워크플로 종속성을 잠그는 이유는 무엇인가요?

워크플로는 태그 또는 브랜치(예: uses: octo-org/deploy-action@v3 또는 uses: octo-org/deploy-action@main)로 작업을 참조하는 경우가 많습니다. GitHub Actions 는 런타임에 태그 또는 브랜치가 가리키는 커밋에 대한 참조를 확인합니다.

태그 및 브랜치는 이동할 수 있습니다. 따라서 실행되는 코드가 워크플로 작성자가 원래 검토한 코드라고 보장할 수 없습니다. 업스트림 유지 관리자의 계정이 손상되고 태그를 다시 지정하면 리포지토리가 악성 코드를 실행할 수 있습니다.

워크플로 종속성 잠금 파일은 전이적 종속성을 포함하여 워크플로가 종속하는 모든 작업에 커밋 SHA를 고정합니다. 다시 사용할 수 있는 워크플로(jobs.<job_id>.uses)에 대한 호출을 pin하지 않습니다. 재사용 가능한 워크플로를 고정하려면 전체 커밋 SHA로 참조합니다. lockfile은 러너에서 어떤 액션 코드가 실행되는지 제어합니다. 입력 매개 변수, 시크릿 또는 실행기 이미지와 같은 다른 빌드 입력을 제어하지 않습니다. lockfile은 적용되는 작업 코드에 대해 다음을 제공합니다.

  • 작업 종속성의 재현 가능한 확인
  • 검토 가능한 종속성 변경 및 Dependabot 버전 업데이트
  • 귀하의 CI/CD 시스템의 작업 종속성에 대한 감사 가능한 인벤토리

잠금 파일은 어떻게 작동하나요?

lockfile은 .github/workflows/actions.lock에 있는 리포지토리에서 정의됩니다. gh actions-lock은(는) GitHub CLI 확장 프로그램에 의해 생성되며 수동으로 직접 편집해서는 안 됩니다.

리포지토리의 워크플로를 하나씩 또는 한꺼번에 잠금 파일에 온보딩할 수 있습니다. 워크플로가 온보딩된 후:

  • 워크플로에서 사용하는 모든 작업 종속성은 잠금 파일에 있어야 합니다.
  • 잠긴 커밋은 워크플로가 실행될 때 실행되는 항목이며, 허용된 작업 정책이 확인하는 대상입니다.
  • 이 커밋은 작업 자체 리포지토리의 lockfile에 기록된 브랜치 또는 태그로부터 도달 가능해야 합니다. 포크에만 존재하거나 해당 브랜치 또는 태그에서 더 이상 도달할 수 없는 커밋은 워크플로가 실행되면 거부됩니다.

잠금 파일은 재사용 가능한 워크플로 호출의 종속성을 제외하고 전이적 종속성(사용자 작업 종속성에서 사용하는 작업)을 포함하여 자체 리포지토리의 워크플로를 다룹니다. 재사용 가능한 워크플로에는 자체 잠금 파일도 있을 수 있습니다. 재사용 가능한 워크플로의 종속성은 리포지토리를 호출하는 리포지토리의 lockfile이 아니라 정의된 리포지토리의 잠금 파일로 처리됩니다.

lockfile에는 무엇이 기록되나요?

lockfile에는 두 개의 섹션이 있습니다. workflows는 온보딩된 각 워크플로에서 사용하는 종속성을 기록하고, dependencies는 이러한 각 참조가 확인되는 커밋을 기록합니다.

# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
# Docs: https://gh.io/actions-lockfile
version: 'v0.0.3'
workflows:
    '.github/workflows/ci.yml':
        - 'octo-org/deploy-action@v3.1.0'
dependencies:
    'octo-org/deploy-action@v3.1.0':
        ref: 'v3.1.0'
        commit: 'sha1-...'
        owner_id: 44036562
        repo_id: 197814629

각 종속성은 다음을 기록합니다:

  • ref: 커밋이 파생된 태그 또는 분기입니다.
  • commit: 참조가 가리키는 정확한 커밋입니다. 실행할 코드입니다.
  • owner_id 및 repo_id: 원본 리포지토리의 숫자 ID입니다. GitHub Actions에서는 이러한 값을 사용하여 런타임에 이름에 해당하는 리포지토리가 여전히 잠근 리포지토리와 동일한지 확인합니다.

이 구조화된 형식은 YAML 주석을 버전 주석으로 사용하지 않고도 Dependabot와 같은 도구가 종속성 업데이트를 관리하는 데 사용할 수 있는 컴퓨터가 읽을 수 있는 레코드를 제공합니다.

잠금 파일은 SHA 고정과 비교하면 어떻습니까?

GitHub는 지금까지 워크플로 파일에서 타사 작업을 전체 길이 커밋 SHA에 고정하도록 권장해 왔습니다. 잠금 파일을 채택하는 리포지토리의 경우 워크플로 파일 내에서 SHA 고정이 더 이상 필요하지 않습니다. 잠금 파일이 더 나은 옵션인 이유는 다음과 같습니다:

  • 전이적 종속성 지원
  • 워크플로 파일을 더 쉽게 읽을 수 있도록 합니다.
  • 원본 리포지토리의 ID를 기록합니다.

또한 잠금 파일은 해당 정책에 온보딩된 워크플로에 대해 별도의 작업을 전체 길이 커밋 SHA에 고정하도록 요구 정책도 충족합니다. 워크플로 실행 관리을(를) 참조하세요.

다음 단계

리포지토리에 대한 잠금 파일을 만들려면 리포지토리의 워크플로에서 액션 종속성 잠금을 참조하세요.