참고: 사이트 관리자가 먼저 GitHub Enterprise Server 인스턴스의 Dependabot updates을(를) 설정해야 이 기능을 사용할 수 있습니다. 자세한 내용은 "엔터프라이즈에 Dependabot 사용"을(를) 참조하세요.
엔터프라이즈 소유자가 엔터프라이즈 수준에서 정책을 설정한 경우 Dependabot updates을(를) 사용하거나 사용하지 않도록 설정할 수 없습니다. 자세한 내용은 "엔터프라이즈에 대한 코드 보안 및 분석을 위한 정책 적용"을(를) 참조하세요.
dependabot.yml
파일 정보
Dependabot 구성 파일인 dependabot.yml
은 YAML 구문을 사용합니다. YAML을 처음 사용하며 자세히 알아보려는 경우 “5분 안에 YAML 알아보기”를 참조하세요.
해당 파일을 리포지토리의 .github
디렉터리에 기본 분기로 저장해야 합니다. dependabot.yml
파일을 추가하거나 업데이트하면 버전 업데이트 즉시 확인이 트리거됩니다. 자세한 내용과 예제는 "Dependabot 버전 업데이트 구성"을(를) 참조하세요.
보안 업데이트에도 영향을 주는 옵션은 다음에 보안 경고로 보안 업데이트 끌어오기 요청이 트리거될 때 사용됩니다. 자세한 정보는 "Dependabot 보안 업데이트 구성." 항목을 참조하세요.
참고: Dependabot alerts을(를) dependabot.yml
파일로 구성할 수 없습니다.
dependabot.yml
파일에는 두 개의 필수 최상위 키인 version
및 updates
가 있습니다. 필요에 따라 최상위 registries
키를 포함할 수 있습니다. 파일은 version: 2
로 시작해야 합니다.
dependabot.yml
파일의 실제 예제는 Dependabot의 자체 구성 파일을 참조하세요.
dependabot.yml
파일의 구성 옵션
최상위 updates
키는 필수입니다. 이 키를 사용하여 Dependabot이(가) 버전 또는 프로젝트 종속성을 업데이트하는 방법을 구성합니다. 각 항목은 특정 패키지 관리자에 대한 업데이트 설정을 구성합니다. 사용할 수 있는 옵션은 다음과 같습니다.
옵션 | 필수 | 보안 업데이트 | 버전 업데이트 | 설명 |
---|---|---|---|---|
package-ecosystem | 사용할 패키지 관리자 | |||
directory | 패키지 매니페스트 위치 | |||
schedule.interval | 업데이트 확인 빈도 | |||
allow | 허용되는 업데이트를 사용자 지정합니다. | |||
assignees | 끌어오기 요청에 설정할 담당자입니다. | |||
commit-message | 커밋 메시지 기본 설정입니다. | |||
enable-beta-ecosystems | 베타 수준 지원이 있는 에코시스템 활성화 | |||
ignore | ignore 를 참조하세요. | ignore 를 참조하세요. | 특정 종속성 또는 버전을 무시합니다. | |
insecure-external-code-execution | 매니페스트 파일의 코드 실행을 허용하거나 거부합니다. | |||
labels | 끌어오기 요청에 설정할 레이블입니다. | |||
milestone | 끌어오기 요청에 설정할 마일스톤입니다. | |||
open-pull-requests-limit | 버전 업데이트를 위해 열린 끌어오기 요청 수를 제한합니다. | |||
pull-request-branch-name.separator | 끌어오기 요청 분기 이름의 구분 기호를 변경합니다. | |||
rebase-strategy | 자동 다시 지정을 사용하지 않도록 설정합니다. | |||
registries | Dependabot이 액세스할 수 있는 프라이빗 레지스트리입니다. | |||
reviewers | 끌어오기 요청에 설정할 검토자입니다. | |||
schedule.day | 업데이트를 확인하는 요일입니다. | |||
schedule.time | 업데이트를 확인하는 하루 중 시간(hh:mm)입니다. | |||
schedule.timezone | 하루 중 시간의 표준 시간대(영역 식별자)입니다. | |||
target-branch | 끌어오기 요청을 만들 분기입니다. | |||
vendor | 벤더링된 종속성 또는 캐시된 종속성을 업데이트합니다. | |||
versioning-strategy | 매니페스트 버전 요구 사항을 업데이트하는 방법입니다. | |||
옵션은 광범위하게 다음 범주로 분류됩니다. |
- 모든 구성에 포함해야 하는 필수 설정 옵션:
package-ecosystem
,directory
,schedule.interval
. - 업데이트 일정을 사용자 지정하는 옵션:
schedule.time
,schedule.timezone
,schedule.day
- 업데이트할 종속성을 제어하는 옵션:
allow
,ignore
,vendor
- 끌어오기 요청에 메타데이터를 추가하는 옵션:
reviewers
,assignees
,labels
,milestone
- 끌어오기 요청의 동작을 변경하는 옵션:
target-branch
,versioning-strategy
,commit-message
,rebase-strategy
,pull-request-branch-name.separator
또한 open-pull-requests-limit
옵션은 Dependabot이(가) 버전 업데이트를 위해 열 수 있는 최대 끌어오기 요청 수를 변경합니다.
참고: 일부 구성 옵션은 취약한 패키지 매니페스트의 보안 업데이트에 대해 발생한 끌어오기 요청에도 영향을 줄 수 있습니다.
보안 업데이트는 기본 분기의 취약한 패키지 매니페스트에 대해서만 발생합니다. 구성 옵션이 동일한 분기에 대해 설정되고(target-branch
를 사용하지 않는 한 true) 취약한 매니페스트의 package-ecosystem
및 directory
를 지정하면 보안 업데이트를 위한 끌어오기 요청이 관련 옵션을 사용합니다.
일반적으로 보안 업데이트는 끌어오기 요청에 영향을 주는 구성 옵션(예: 메타데이터 추가 또는 끌어오기 요청의 동작 변경)을 사용합니다. 보안 업데이트에 대한 자세한 내용은 "Dependabot 보안 업데이트 구성."을 참조하세요.
package-ecosystem
필수입니다. Dependabot에서 새 버전을 모니터링할 각 패키지 관리자에 대해 package-ecosystem
요소를 하나씩 추가합니다. 리포지토리에 각 패키지 관리자의 종속성 매니페스트 또는 잠금 파일도 포함되어야 합니다.
벤더링을 지원하는 패키지 관리자에서 벤더링을 사용하도록 설정하려는 경우 벤더링된 종속성이 필수 디렉터리에 있어야 합니다. 자세한 내용은 아래의 vendor
을 참조하십시오.
버전 업데이트를 수행할 때 Dependabot이(가) 프라이빗 패킷 레지스트리에 액세스하도록 허용하려면 구성 파일에 registries
설정을 포함하면 됩니다. 자세한 내용은 아래 registries
를 참조하세요.
참고: 엔터프라이즈 소유자는 Dependabot 작업의 최신 버전을 다운로드하여 최상의 에코시스템 범위를 얻을 수 있습니다. 작업에 대한 자세한 내용과 최신 버전을 다운로드하는 방법에 대한 지침은 "최신 버전의 공식 번들 작업 사용"을 참조하세요.
패키지 관리자 | YAML 값 | 지원되는 버전 | 버전 업데이트 | 보안 업데이트 | 프라이빗 리포지토리 | 프라이빗 레지스트리 | 벤더링 |
---|---|---|---|---|---|---|---|
Bundler | bundler | v1, v2 | |||||
Cargo | cargo | v1 | (Git only) | ||||
작성기 | composer | v1, v2 | |||||
Docker | docker | v1 | 해당 없음 | ||||
16진수 | mix | v1 | |||||
elm-package | elm | v0.19 | |||||
git 하위모듈 | gitsubmodule | 해당 없음 | 해당 없음 | ||||
GitHub Actions | github-actions | 해당 없음 | 해당 없음 | ||||
Go 모듈 | gomod | v1 | |||||
Gradle | gradle | 해당 없음 | |||||
Maven | maven | 해당 없음 | |||||
npm | npm | v6, v7, v8, v9 | |||||
NuGet | nuget | <= 4.8 | |||||
pip | pip | v21.1.2 | |||||
pipenv | pip | <= 2021-05-29 | |||||
pip-compile | pip | 6.1.0 | |||||
pnpm | npm | v7, v8, v9 | (v7 and v8 only) | ||||
poetry | pip | v1 | |||||
pub | pub | v2 | |||||
Terraform | terraform | >= 0.13, <= 1.8.x | 해당 없음 | ||||
yarn | npm | v1, v2, v3 |
팁: pipenv
및 poetry
같은 패키지 관리자의 경우 pip
YAML 값을 사용해야 합니다. 예를 들어 poetry
를 사용하여 Python 종속성을 관리하고 Dependabot에서 새 버전의 종속성 매니페스트 파일을 모니터링하기를 원하는 경우 dependabot.yml
파일의 package-ecosystem: "pip"
를 사용합니다.
Dependabot security updates에 대한 에코시스템 지원에 대한 자세한 내용은 "종속성 그래프에서 지원되는 패키지 에코시스템" 섹션을 참조하세요.
Cargo
프라이빗 레지스트리 지원은 Git 레지스트리에 적용되며 Cargo 레지스트리를 포함하지 않습니다.
Docker
Dependabot은(는) Docker 이미지의 메타데이터를 추가하여 버전 업데이트 요청을 끌어올 수 있습니다. 메타데이터에는 릴리스 정보, 변경 로그 및 커밋 기록이 포함됩니다. 리포지토리 관리자는 메타데이터를 사용하여 종속성 업데이트의 안정성 위험을 신속하게 평가할 수 있습니다.
Dependabot이(가) Docker 메타데이터를 가져오려면 Docker 이미지의 유지 관리자는 Dockerfile에 org.opencontainers.image.source
레이블을 추가하고 원본 리포지토리의 URL을 포함해야 합니다. 또한 유지 관리자는 게시된 Docker 이미지와 동일한 태그를 사용하여 리포지토리에 태그를 지정해야 합니다. 예제는 dependabot-fixtures/docker-with-source
리포지토리를 참조하세요. Docker 레이블에 대한 자세한 내용은 Docker 설명서의 확장 이미지 레이블 및 BUILDX_GIT_LABELS를 참조하세요.
Dependabot은(는) Kubernetes 매니페스트에서 Docker 이미지 태그를 업데이트할 수 있습니다. Docker 이미지 태그를 참조하는 Kubernetes 매니페스트를 포함하는 각 디렉터리에 대한 dependabot.yml
파일의 Docker package-ecosystem
요소에 항목을 추가합니다. Kubernetes 매니페스트는 Kubernetes 배포 YAML 파일 또는 Helm 차트일 수 있습니다. docker
에 대한 dependabot.yml
파일을 구성하는 방법에 대한 자세한 내용은 "dependentabot.yml 파일 구성 옵션"의 "package-ecosystem
"을 참조하세요.
Dependabot은(는) 퍼블릭 및 프라이빗 Docker 레지스트리를 모두 지원합니다. 이러한 레지스트리의 목록은 "dependentabot.yml 파일 구성 옵션"의 “docker-registry
”를 참조하세요.
Dependabot은(는) 유의적 버전(SemVer)에 대한 Docker 이미지 태그를 구문 분석합니다. If Dependabot이(가) 시험판에서 태그를 검색한 경우 일치하는 시험판을 포함하는 최신 버전으로의 업데이트만 제안하며 다른 시험판 레이블을 사용하는 최신 버전은 제안하지 않습니다. 자세한 내용은 dependabot/dependabot-core
리포지토리에서 dependabot-docker
README.md 파일을 참조하세요.
GitHub Actions
Dependabot은 다음과 같은 주의 사항과 함께 GitHub Actions의 버전 업데이트를 지원합니다.
- Dependabot은(는) % data variables.product.prodname_dotcom %} 리포지토리 구문(예:
actions/checkout@v4
)을 사용하여 GitHub Actions에 대한 업데이트만 지원합니다. Dependabot은(는) 로컬에서 참조되는 작업 또는 재사용 가능한 워크플로(예:./.github/actions/foo.yml
)를 무시합니다. - Docker 허브 및 GitHub Packages Container registry URL은 현재 지원되지 않습니다. 예를 들어
docker://
구문을 사용하는 Docker 컨테이너 작업에 대한 참조는 지원되지 않습니다. - Dependabot은(는) GitHub Actions에 대한 퍼블릭 및 프라이빗 리포지토리를 모두 지원합니다. 프라이빗 레지스트리 구성 옵션은 "dependentabot.yml 파일 구성 옵션"의 "
git
"를 참조하세요.
GitHub Actions과 함께 Dependabot version updates을 사용하는 방법에 대한 자세한 내용은 "GitHub의 보안 기능을 사용하여 안전하게 GitHub Actions 사용"을(를) 참조하세요.
Gradle
Gradle은 Dependabot version updates에만 지원됩니다.
Dependabot은(는) Gradle을 실행하지 않지만 다음 파일에 대한 업데이트를 지원합니다.
build.gradle
,build.gradle.kts
(Kotlin 프로젝트의 경우)gradle/libs.versions.toml
(표준 Gradle 버전 카탈로그를 사용하는 프로젝트의 경우)- 파일 이름에
dependencies
이 있는apply
선언을 통해 포함된 파일입니다.apply
는apply to
, 재귀 또는 고급 구문(예: 속성에 의해 정의된 파일 이름인mapOf
와 함께 Kotlin의apply
)을 지원하지 않습니다.
Dependabot은 pom.xml
종속성 파일의 정보를 사용하여 업데이트 끌어오기 요청의 릴리스 정보에 대한 링크를 추가합니다. pom.xml
파일에서 정보를 생략하면 Dependabot 끌어오기 요청에 포함할 수 없습니다. "Dependabot 업데이트에 Java 패키지 최적화"을(를) 참조하세요.
Maven
Dependabot은(는) Maven을 실행하지 않지만 pom.xml
파일에 대한 업데이트를 지원합니다.
Dependabot은 pom.xml
종속성 파일의 정보를 사용하여 업데이트 끌어오기 요청의 릴리스 정보에 대한 링크를 추가합니다. pom.xml
파일에서 정보를 생략하면 Dependabot 끌어오기 요청에 포함할 수 없습니다. "Dependabot 업데이트에 Java 패키지 최적화"을(를) 참조하세요.
NuGet CLI
Dependabot은(는) NuGet CLI를 실행하지 않지만, 4.8 버전까지 대부분의 기능을 지원합니다.
pip 및 pip-compile
Dependabot은(는) requirements.txt
파일 업데이트 지원하는 외에도 PEP 621 표준을 따르는 경우 pyproject.toml
파일에 대한 업데이트를 지원합니다.
pnpm
pnpm은 Dependabot version updates(v7, v8 및 v9에만 해당) 및 Dependabot security updates(v7 및 v8에만 해당)에 대해 지원됩니다.
pub
Dependabot은(는) pub
를 업데이트하려는 버전이 무시될 경우 이전 버전을 사용할 수 있더라도 업데이트를 수행하지 않습니다.
Terraform
Terraform 지원에는 다음이 포함됩니다.
- Terraform 레지스트리 또는 공개적으로 연결할 수 있는 Git 리포지토리에서 호스트되는 모듈
- Terraform 공급자.
- 비공개 Terraform 레지스트리.
dependabot.yml
파일에 git 레지스트리를 지정하여 비공개 git 리포지토리에 대한 액세스를 구성할 수 있습니다. 자세한 내용은git
를 참조하세요.
yarn
Dependabot은 v2 이상에 대한 공급업체 종속성을 지원합니다.
3가지 패키지 관리자 기본 설정의 예시
# Basic set up for three package managers
version: 2
updates:
# Maintain dependencies for GitHub Actions
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for npm
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for Composer
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
directory
필수입니다. 각 패키지 관리자의 패키지 매니페스트(예: package.json 또는 Gemfile) 위치를 정의해야 합니다. GitHub Actions을(를) 제외한 모든 에코시스템에 대해 리포지토리 루트의 상대 디렉터리를 정의합니다.
GitHub Actions의 경우 디렉터리를 /.github/workflows
(으)로 설정할 필요가 없습니다. 키를 /
(으)로 구성하면 Dependabot에 /.github/workflows
디렉터리뿐 아니라 루트 디렉터리의 action.yml / action.yaml 파일도 검색하도록 자동으로 지시합니다.
# Specify location of manifest files for each package manager
version: 2
updates:
- package-ecosystem: "composer"
# Files stored in repository root
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "npm"
# Files stored in `app` directory
directory: "/app"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
interval: "weekly"
schedule.interval
필수입니다. 각 패키지 관리자에서 새 버전을 확인하는 빈도를 정의해야 합니다. 기본적으로 Dependabot은 구성 파일에서 모든 업데이트를 적용하는 시간을 임의로 할당합니다. 특정 시간을 설정하기 위해 schedule.time
및 schedule.timezone
을 사용할 수 있습니다.
참고: schedule.time
옵션이 최선이며, Dependabot이 끌어오기 요청을 열어 최신 종속성 버전으로 업데이트하기까지 다소 시간이 걸릴 수 있습니다.
간격 유형 | 빈도 |
---|---|
daily | 평일(월요일~금요일)에 매일 실행됩니다. |
weekly | 매주 한 번 실행됩니다. 기본적으로 월요일에 실행됩니다. 이 설정을 수정하려면 schedule.day 를 사용합니다. |
monthly | 매월 한 번 실행됩니다. 매월 1일에 실행됩니다. |
# Set update schedule for each package manager
version: 2
updates:
- package-ecosystem: "github-actions"
# Workflow files stored in the default location of `.github/workflows`. (You don't need to specify `/.github/workflows` for `directory`. You can use `directory: "/"`.)
directory: "/"
schedule:
# Check for updates to GitHub Actions every weekday
interval: "daily"
- package-ecosystem: "composer"
directory: "/"
schedule:
# Check for updates managed by Composer once a week
interval: "weekly"
참고: schedule
은 Dependabot이 새 업데이트를 시도하는 시기를 정의합니다. 그러나 이때만 끌어오기 요청을 받을 수 있는 것은 아닙니다. dependabot.yml
파일 변경 내용, 업데이트 실패 후 매니페스트 파일 변경 내용 또는 Dependabot security updates에 따라 업데이트가 트리거될 수 있습니다. 자세한 내용은 "Dependabot 버전 업데이트 정보" 및 "Dependabot 보안 업데이트 정보" 항목을 참조하세요.
allow
기본적으로 매니페스트에 명시적으로 정의된 모든 종속성은 보안 업데이트는 잠긴 파일에 정의된 취약한 종속성도 업데이트합니다. 유지 관리할 종속성이 있는 allow
및 ignore
을(를) 사용자 지정할 수 있습니다. Dependabot은 허용되는 모든 종속성을 확인한 다음, 무시된 종속성 또는 버전을 필터링합니다. 따라서 allow
및 ignore
둘 다와 일치하는 종속성이 무시됩니다.
allow
옵션을 사용하여 업데이트되는 종속성을 사용자 지정할 수 있습니다. 버전 및 보안 업데이트에 모두 적용됩니다. 사용할 수 있는 옵션은 다음과 같습니다.
-
dependency-name
- 이름이 일치하는 종속성 업데이트를 허용하려면 사용합니다. 필요에 따라 0자 이상의 문자와 일치하도록*
를 사용합니다.- Java 종속성의 경우
dependency-name
특성의 형식은groupId:artifactId
입니다(예:org.kohsuke:github-api
). - Docker 이미지 태그의 형식은 리포지토리의 전체 이름입니다. 예를 들어
<account ID>.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc
의 이미지 태그는base/foo/bar/ruby
를 사용합니다.
- Java 종속성의 경우
-
dependency-type
- 특정 형식의 종속성 업데이트를 허용하려면 사용합니다.종속성 유형 지원하는 패키지 관리자 업데이트 허용 direct
모두 명시적으로 정의된 모든 종속성. indirect
bundler
,pip
,composer
,cargo
,gomod
직접 종속성의 종속성(하위 종속성 또는 일시적인 종속성이라고도 함) all
모두 명시적으로 정의된 모든 종속성. bundler
,pip
,composer
,cargo
,gomod
의 경우 직접 종속성의 종속성 업데이트도 허용됩니다.production
bundler
,composer
,mix
,maven
,npm
,pip
(모든 관리자가 아님)“프로덕션 종속성 그룹”의 종속성만 development
bundler
,composer
,mix
,maven
,npm
,pip
(모든 관리자가 아님)“개발 종속성 그룹”의 종속성만
# Use `allow` to specify which dependencies to maintain
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow updates for Lodash
- dependency-name: "lodash"
# Allow updates for React and any packages starting "react"
- dependency-name: "react*"
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow both direct and indirect updates for all packages
- dependency-type: "all"
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
allow:
# Allow only direct updates for
# Django and any packages starting "django"
- dependency-name: "django*"
dependency-type: "direct"
# Allow only production updates for Sphinx
- dependency-name: "sphinx"
dependency-type: "production"
assignees
assignees
를 사용하여 패키지 관리자에 대해 발생한 모든 끌어오기 요청의 개별 담당자를 지정할 수 있습니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Specify assignees for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Add assignees
assignees:
- "octocat"
commit-message
기본적으로 Dependabot은 커밋 메시지 기본 설정을 검색하고 유사한 패턴을 사용하려고 합니다. commit-message
옵션을 사용하여 기본 설정을 명시적으로 지정할 수 있습니다. 이 설정은 끌어오기 요청의 제목에도 영향을 줍니다.
명시적으로 설정하든 리포지토리 기록에서 자동으로 검색되든 관계없이 커밋 메시지를 기반으로 끌어오기 요청의 제목을 채웁니다.
지원되는 옵션
참고: prefix
및 prefix-development
옵션은 50자로 제한됩니다.
-
prefix
는 모든 커밋 메시지 대한 접두사를 지정하며 PR 제목의 시작 부분에도 추가됩니다. 커밋 메시지에 접두사를 지정할 때 정의된 접두사가 글자, 숫자, 닫는 괄호 또는 닫는 대괄호로 끝나는 경우 GitHub가 정의된 접두사와 커밋 메시지 사이에 콜론을 자동으로 추가합니다. 예를 들어 접두사를 공백으로 끝내면 접두사와 커밋 메시지 사이에 콜론이 추가되지 않습니다. 아래의 코드 조각은 동일한 구성 파일에 있는 두 가지 예제를 제공합니다. -
prefix-development
는 개발 종속성 그룹의 종속성을 업데이트하는 모든 커밋 메시지에 대해 별도의 접두사를 지정합니다. 이 옵션의 값을 지정한 경우prefix
는 프로덕션 종속성 그룹의 종속성 업데이트에만 사용됩니다.bundler
,composer
,mix
,maven
,npm
,pip
에서 지원됩니다. -
include: "scope"
는 커밋에서 업데이트되는 종속성 유형(deps
또는deps-dev
)이 접두사 뒤에 오도록 지정합니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Customize commit messages
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
commit-message:
# Prefix all commit messages with "npm: "
prefix: "npm"
- package-ecosystem: "docker"
directory: "/"
schedule:
interval: "weekly"
commit-message:
# Prefix all commit messages with "[docker] " (no colon, but a trailing whitespace)
prefix: "[docker] "
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
# Prefix all commit messages with "Composer" plus its scope, that is, a
# list of updated dependencies
commit-message:
prefix: "Composer"
include: "scope"
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Include a list of updated dependencies
# with a prefix determined by the dependency group
commit-message:
prefix: "pip prod"
prefix-development: "pip dev"
위 예제와 동일한 구성을 사용하는 경우 pip
개발 종속성 그룹에서 requests
라이브러리를 업그레이드하면 다음 커밋 메시지가 생성됩니다.
pip dev: bump requests from 1.0.0 to 1.0.1
ignore
기본적으로 매니페스트에 명시적으로 정의된 모든 종속성은 보안 업데이트는 잠긴 파일에 정의된 취약한 종속성도 업데이트합니다. 유지 관리할 종속성이 있는 allow
및 ignore
을(를) 사용자 지정할 수 있습니다. Dependabot은 허용되는 모든 종속성을 확인한 다음, 무시된 종속성 또는 버전을 필터링합니다. 따라서 allow
및 ignore
둘 다와 일치하는 종속성이 무시됩니다.
ignore
에 종속성을 추가하거나 Dependabot에서 열린 끌어오기 요청에 @dependabot ignore
명령을 사용하여 종속성을 무시할 수 있습니다.
경고:
-
Dependabot의 비공개 레지스트리 액세스를 방지하는 데
ignore
을(를) 사용하지 않는 것이 좋습니다. 이 방식은 일부 에코시스템에서는 작동할 수 있지만 패키지 관리자가 업데이트를 성공적으로 수행하기 위해 모든 종속성에 대한 액세스가 필요한지 여부를 알 수 없으므로 해당 방식을 신뢰할 수 없습니다. 비공개 종속성 처리를 지원하는 방법은 비공개 레지스트리 또는 프라이빗 리포지토리에 대해 Dependabot 액세스 권한을 부여하는 것입니다. 자세한 내용은 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요. -
GitHub Actions 및 Docker의 경우
ignore
을(를) 사용하여 Dependabot이(가) 비공개 레지스트리에 액세스하지 못하도록 방지할 수 있습니다.
@dependabot ignore
의 ignore
조건 만들기
@dependabot ignore
명령을 사용하여 무시된 종속성은 패키지 관리자별로 중앙에서 저장됩니다. dependabot.yml
파일에서 종속성을 무시하기 시작하면 구성의 ignore
종속성과 함께 기존 기본 설정이 고려됩니다.
리포지토리에서 "@dependabot ignore" in:comments
를 검색하거나 @dependabot show DEPENDENCY_NAME ignore conditions
주석 명령을 사용하여 리포지토리에 저장된 ignore
기본 설정이 있는지 확인할 수 있습니다. 이런 방법으로 무시된 종속성의 업데이트를 차단 해제하려면 끌어오기 요청을 다시 엽니다. 그러면 끌어오기 요청이 닫힐 때 설정된 ignore
조건이 지워지고 해당 종속성에 대한 Dependabot 업데이트가 다시 시작됩니다. 종속성을 최신 버전으로 업데이트하려면 끌어오기 요청을 병합합니다.
@dependabot ignore
명령에 대한 자세한 내용은 "종속성 업데이트에 대한 끌어오기 요청 관리"를 참조하세요.
무시할 종속성 및 버전 지정
ignore
옵션을 사용하여 업데이트되는 종속성을 사용자 지정할 수 있습니다. ignore
옵션에서 지원하는 옵션은 다음과 같습니다.
옵션 | 설명 |
---|---|
dependency-name | 이름이 일치하는 종속성에 대한 업데이트를 무시하는 데 사용하며, 필요에 따라 0자 이상의 문자와 일치하도록 * 를 사용합니다.Java 종속성의 경우 dependency-name 특성의 형식은 groupId:artifactId 입니다(예: org.kohsuke:github-api ).Dependabot이(가) DefinitelyTyped에서 TypeScript 유형 정의를 자동으로 업데이트하는 것을 방지하려면 @types/* 를 사용합니다. |
versions | 특정 버전 또는 버전 범위를 무시하는 데 사용합니다. 범위를 정의하려는 경우 패키지 관리자의 표준 패턴을 사용합니다. 예를 들어 npm에는 ^1.0.0 , 번들러에는 ~> 2.0 , Docker에는 Ruby 버전 구문, NuGet에는 7.* 을 사용합니다. |
update-types | 버전 업데이트에서 semver major , minor 또는 patch 업데이트와 같은 유형의 업데이트를 무시하는 데 사용합니다(예: version-update:semver-patch 는 패치 업데이트를 무시함). dependency-name: "*" 와 결합하여 모든 종속성에서 특정 update-types 를 무시할 수 있습니다.현재 지원되는 옵션은 version-update:semver-major , version-update:semver-minor , version-update:semver-patch 뿐입니다. |
단독으로 사용하는 경우 ignore.versions
키는 Dependabot 업데이트 모두에 영향을 주지만 ignore.update-types
키는 Dependabot version updates에만 영향을 줍니다.
그러나 versions
및 update-types
를 동일한 ignore
규칙에서 사용하는 경우, 기본 분기가 아닌 분기에서 버전 업데이트를 확인하기 위해 구성이 target-branch
를 사용하지 않는 한 Dependabot 업데이트 모두에 영향을 줍니다.
# Use `ignore` to specify dependencies that should not be updated
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
ignore:
- dependency-name: "express"
# For Express, ignore all Dependabot updates for version 4 and 5
versions: ["4.x", "5.x"]
# For Lodash, ignore all updates
- dependency-name: "lodash"
# For AWS SDK, ignore all patch updates for version updates only
- dependency-name: "aws-sdk"
update-types: ["version-update:semver-patch"]
- package-ecosystem: 'github-actions'
directory: '/'
schedule:
interval: 'weekly'
ignore:
- dependency-name: 'actions/checkout'
# For GitHub Actions, ignore all updates greater than or equal to version 3
versions: '>= 3'
참고: Dependabot은 구성 파일의 ignore
옵션에 액세스할 수 없는 종속성을 추가하더라도 파일의 모든 종속성에 액세스할 수 있는 경우에만 매니페스트 또는 잠금 파일에서 버전 업데이트를 실행할 수 있습니다. 자세한 내용은 "조직의 보안 및 분석 설정 관리" 및 "Dependabot 오류 문제 해결"을(를) 참조하세요.
참고: pub
에코시스템의 경우 이전 버전을 사용할 수 있더라도 Dependabot은 업데이트를 시도하는 버전이 무시될 때 업데이트를 수행하지 않습니다.
다음 예는 ignore
을 사용하여 업데이트되는 종속성을 사용자 지정하는 방법을 보여줍니다.
특정 버전 이외의 업데이트 무시
ignore:
- dependency-name: "lodash:*"
versions: [ ">=1.0.0" ]
특정 버전 이외의 업데이트 무시
ignore:
- dependency-name: "sphinx"
versions: [ "[1.1,)" ]
패치 업데이트 무시
ignore:
- dependency-name: "@types/node"
update-types: ["version-update:semver-patch"]
특정 버전의 업데이트 무시
ignore:
- dependency-name: "django*"
versions: [ "11" ]
insecure-external-code-execution
package-ecosystem
값이 bundler
, mix
, pip
인 패키지 관리자는 버전 업데이트 프로세스의 일부로 매니페스트의 외부 코드를 실행할 수 있습니다. 이로 인해 손상된 패키지가 자격 증명을 도용하거나 구성된 레지스트리에 대한 액세스 권한을 얻을 수 있습니다. updates
구성 내에 registries
설정을 추가하면 Dependabot이 자동으로 외부 코드 실행을 방지합니다. 이 경우 버전 업데이트에 실패할 수 있습니다. insecure-external-code-execution
을 allow
로 설정하면 이 동작을 재정의하고 bundler
, mix
, pip
패키지 관리자의 외부 코드 실행을 허용할 수 있습니다.
# Allow external code execution when updating dependencies from private registries
version: 2
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
updates:
- package-ecosystem: "bundler"
directory: "/rubygems-server"
insecure-external-code-execution: allow
registries: "*"
schedule:
interval: "monthly"
Dependabot이 프라이빗 패키지 레지스트리에 액세스할 수 있도록 registries
설정을 정의하고 동일한 updates
구성에서 insecure-external-code-execution
를 allow
로 설정한 경우 발생하는 외부 코드 실행은 해당 updates
설정과 연결된 레지스트리의 패키지 관리자에만 액세스할 수 있습니다. 최상위 registries
구성에 정의된 레지스트리에는 액세스가 허용되지 않습니다.
이 예제에서 구성 파일을 사용하면 Dependabot에서 ruby-github
프라이빗 패키지 레지스트리에 액세스할 수 있습니다. 동일한 updates
설정에서 insecure-external-code-execution
이 allow
로 설정되어 있으므로 종속성으로 실행되는 코드는 dockerhub
레지스트리가 아닌 ruby-github
레지스트리에만 액세스하게 됩니다.
# Using `registries` in conjunction with `insecure-external-code-execution:allow`
# in the same `updates` setting
version: 2
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
dockerhub:
type: docker-registry
url: registry.hub.docker.com
username: octocat
password: ${{secrets.DOCKERHUB_PASSWORD}}
updates:
- package-ecosystem: "bundler"
directory: "/rubygems-server"
insecure-external-code-execution: allow
registries:
- ruby-github # only access to registries associated with this ecosystem/directory
schedule:
interval: "monthly"
insecure-external-code-execution
을 deny
로 설정하면 이 업데이트 구성에 대한 registries
설정이 있는지 여부에 관계없이 외부 코드 실행을 명시적으로 거부할 수 있습니다.
labels
기본적으로 Dependabot은 dependencies
레이블을 사용하여 모든 끌어오기 요청을 발생시킵니다. 둘 이상의 패키지 관리자가 정의된 경우 Dependabot은 각 끌어오기 요청에 추가 레이블을 포함합니다. 이는 끌어오기 요청이 업데이트할 언어 또는 에코시스템을 나타냅니다(예: Gradle 업데이트의 경우 java
, git 하위 모듈 업데이트의 경우 submodules
). Dependabot은 리포지토리에서 필요에 따라 기본 레이블을 자동으로 만듭니다.
기본 레이블을 재정의하고 패키지 관리자에 대해 발생한 모든 끌어오기 요청의 대체 레이블을 지정하려면 labels
를 사용합니다. 레이블이 리포지토리에 정의되어 있지 않으면 무시됩니다.
기본 레이블을 포함하여 모든 레이블을 사용하지 않도록 설정하려면 labels: [ ]
를 사용합니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Specify labels for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Specify labels for npm pull requests
labels:
- "npm"
- "dependencies"
milestone
패키지 관리자에 대해 발생한 모든 끌어오기 요청을 마일스톤과 연결하려면 milestone
을 사용합니다. 해당 레이블이 아닌 마일스톤의 숫자 식별자를 지정해야 합니다. 마일스톤을 볼 때 milestone
뒤에 있는 페이지 URL의 최종 부분이 식별자입니다. 예: https://github.com/<org>/<repo>/milestone/3
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Specify a milestone for pull requests
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Associate pull requests with milestone "4"
milestone: 4
open-pull-requests-limit
기본적으로 Dependabot은 버전 업데이트에 대해 최대 5개의 끌어오기 요청을 엽니다. Dependabot에서 열린 끌어오기 요청이 5개 있으면 Dependabot은 열려 있는 요청 중 일부가 병합되거나 닫혀질 때까지 새 요청을 열지 않습니다. 이 한도를 변경하려면 open-pull-requests-limit
를 사용합니다. 이 옵션은 패키지 관리자에 대한 버전 업데이트를 일시적으로 사용하지 않도록 설정하는 간단한 방법도 제공합니다.
열린 끌어오기 요청 10개인 별도의 내부 한도가 있는 보안 업데이트에는 영향을 주지 않습니다.
# Specify the number of open pull requests allowed
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Disable version updates for npm dependencies
open-pull-requests-limit: 0
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Allow up to 10 open pull requests for pip dependencies
open-pull-requests-limit: 10
pull-request-branch-name.separator
Dependabot은 각 끌어오기 요청에 대한 분기를 생성합니다. 각 분기 이름에는 dependabot
과 업데이트되는 패키지 관리자 및 종속성이 포함됩니다. 기본적으로 각 부분은 /
기호로 구분됩니다(예: dependabot/npm_and_yarn/next_js/acorn-6.4.1
).
다른 구분 기호를 지정하려면 pull-request-branch-name.separator
를 사용합니다. "-"
, _
또는 /
중 하나일 수 있습니다. 하이픈 기호는 따옴표로 묶어야 합니다. 그러지 않으면 빈 YAML 목록을 시작하는 것으로 해석됩니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Specify a different separator for branch names
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
pull-request-branch-name:
# Separate sections of the branch name with a hyphen
# for example, `dependabot-npm_and_yarn-next_js-acorn-6.4.1`
separator: "-"
rebase-strategy
기본적으로 Dependabot은 끌어오기 요청의 변경 내용을 검색할 경우 열린 끌어오기 요청을 자동으로 다시 지정합니다. 이 동작을 사용하지 않도록 설정하려면 rebase-strategy
를 사용합니다.
참고: 끌어오기 요청이 30일 동안 병합되지 않은 경우 Dependabot은(는) 끌어오기 요청의 재지정을 중지합니다. 끌어오기 요청을 수동으로 재지정하고 병합할 수 있습니다.
사용 가능한 다시 지정 전략
auto
- 기본 동작을 사용하고 변경 내용이 검색될 경우 열린 끌어오기 요청을 다시 지정합니다.disabled
- 자동 다시 지정을 사용하지 않도록 설정합니다.
rebase-strategy
를 auto
로 설정하면 Dependabot은 다음과 같은 경우에 끌어오기 요청을 다시 지정하려고 시도합니다.
- 일정이 실행될 때 열려 있는 모든 Dependabot 끌어오기 요청에 대해 Dependabot version updates를 사용하는 경우.
- 닫힌 Dependabot 끌어오기 요청을 다시 여는 경우.
- Dependabot 구성 파일의
target-branch
값을 변경하는 경우. 이 필드에 대한 자세한 내용은 "target-branch
"를 참조하세요. - 대상 분기에 최근 푸시한 후 Dependabot 끌어오기 요청이 충돌하는 것을 Dependabot에서 감지한 경우.
rebase-strategy
를 disabled
로 설정하면 Dependabot이 끌어오기 요청의 재지정을 중지합니다.
참고: 이 동작은 대상 분기와 충돌하는 끌어오기 요청에만 적용됩니다. Dependabot은 rebase-strategy
설정이 변경되기 전에 열린 끌어오기 요청과 예약된 실행의 일부인 끌어오기 요청을 계속해서 재지정합니다(열린 후 30일까지).
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Disable automatic rebasing
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Disable rebasing for npm pull requests
rebase-strategy: "disabled"
registries
Dependabot이 버전 업데이트를 수행할 때 프라이빗 패키지 레지스트리에 액세스할 수 있도록 하려면 관련 updates
구성 내에 registries
설정을 포함해야 합니다.
dependabot.yml
파일에는 registries
키를 사용할 수 있는 2개의 위치가 있습니다.
- 최상위 수준으로 필요한 경우 레지스트리 및 해당 액세스 정보를 정의할 수 있습니다.
updates
블록 내에서registries: "*"
를 사용하여 Dependabot에게 최상위 수준에서 정의한 레지스트리의 일부 또는 전부를 사용하도록 지시할 수 있습니다.
# registries: gradle-artifactory - provides access details for the gradle-artifactory registry
# registries: "*" - allows Dependabot to use all the defined registries specified at the top level
version: 2
registries:
gradle-artifactory:
type: maven-repository
url: https://acme.jfrog.io/artifactory/my-gradle-registry
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
updates:
- package-ecosystem: "gradle"
directory: "/"
registries: "*"
schedule:
interval: "monthly"
자세한 내용은 아래의 “프라이빗 레지스트리에 대한 구성 옵션”을 참조하세요.
비공개 레지스트리를 구성할 때 참고할 권장 사항과 조언, 사용 가능한 옵션에 대한 심층적인 내용은 "Dependabot의 개인 레지스트리 구성에 대한 지침"을(를) 참조하세요.
Dependabot이 bundler
, mix
, pip
패키지 관리자를 사용하여 프라이빗 레지스트리의 종속성을 업데이트할 수 있도록 하려면 외부 코드 실행을 허용할 수 있습니다. 자세한 내용은 위의 insecure-external-code-execution
을 참조하세요.
# Allow Dependabot to use one of the two defined private registries
# when updating dependency versions for this ecosystem
version: 2
registries:
maven-github:
type: maven-repository
url: https://maven.pkg.github.com/octocat
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
npm-npmjs:
type: npm-registry
url: https://registry.npmjs.org
username: octocat
password: ${{secrets.MY_NPM_PASSWORD}}
updates:
- package-ecosystem: "gitsubmodule"
directory: "/"
registries:
- maven-github
schedule:
interval: "monthly"
reviewers
패키지 관리자에 대해 발생한 모든 끌어오기 요청의 개별 검토자 또는 검토자 팀을 지정하려면 reviewers
를 사용합니다. 팀을 @mentioning하는 것처럼 조직을 포함한 전체 팀 이름을 사용해야 합니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
# Specify reviewers for pull requests
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Add reviewers
reviewers:
- "octocat"
- "my-username"
- "my-org/python-team"
schedule.day
weekly
업데이트 일정을 설정하는 경우 기본적으로 Dependabot은 월요일, 임의로 설정된 시간에 리포지토리에서 새 버전을 확인합니다. 업데이트를 확인할 대체 요일을 지정하려면 schedule.day
를 사용합니다.
지원되는 값
monday
tuesday
wednesday
thursday
friday
saturday
sunday
# Specify the day for weekly checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates on Sundays
day: "sunday"
schedule.time
기본적으로 Dependabot은 임의로 설정된 시간에 리포지토리에서 새 버전을 확인합니다. 업데이트를 확인할 대체 시간을 지정하려면 schedule.time
을 사용합니다(형식: hh:mm
).
# Set a time for checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates at 9am UTC
time: "09:00"
schedule.timezone
기본적으로 Dependabot은 임의로 설정된 시간에 리포지토리에서 새 버전을 확인합니다. 대체 표준 시간대를 지정하려면 schedule.timezone
을 사용합니다. 표준 시간대 식별자는 iana에서 유지 관리하는 표준 시간대 데이터베이스에서 가져온 것이어야 합니다. 자세한 내용은 tz 데이터베이스 표준 시간대 목록을 참조하세요.
# Specify the timezone for checks
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
time: "09:00"
# Use Japan Standard Time (UTC +09:00)
timezone: "Asia/Tokyo"
target-branch
기본적으로 Dependabot은 기본 분기의 매니페스트 파일을 확인하고 이 분기에 대해 버전 업데이트 끌어오기 요청을 생성합니다. 매니페스트 파일 및 끌어오기 요청에 대해 다른 분기를 지정하려면 target-branch
를 사용합니다. 이 옵션을 사용하면 패키지 관리자 설정이 보안 업데이트에 대해 발생한 끌어오기 요청에 더 이상 영향을 주지 않습니다.
# Specify a non-default branch for pull requests for pip
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
# Raise pull requests for version updates
# to pip against the `develop` branch
target-branch: "develop"
# Labels on pull requests for version updates only
labels:
- "pip dependencies"
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Check for npm updates on Sundays
day: "sunday"
# Labels on pull requests for security and version updates
labels:
- "npm dependencies"
vendor
업데이트할 때 종속성을 벤더링하도록 Dependabot에 지시하려면 vendor
옵션을 사용합니다. gomod
를 사용하는 경우에는 이 옵션을 사용하지 마세요. Dependabot에서 이 도구의 벤더링을 자동으로 검색합니다.
# Configure version updates for both dependencies defined in manifests and vendored dependencies
version: 2
updates:
- package-ecosystem: "bundler"
# Raise pull requests to update vendored dependencies that are checked in to the repository
vendor: true
directory: "/"
schedule:
interval: "weekly"
Dependabot은 리포지토리의 특정 디렉터리에 있는 벤더링된 종속성만 업데이트합니다.
패키지 관리자 | 벤더링된 종속성에 필요한 파일 경로 | 자세한 정보 |
---|---|---|
bundler | 종속성이 vendor/cache 디렉터리에 있어야 합니다. 다른 파일 경로는 지원되지 않습니다. | bundle cache 설명서 |
gomod | 경로 요구 사항 없음(종속성은 일반적으로 vendor 디렉터리에 있음) | go mod vendor 설명서 |
versioning-strategy
Dependabot은 버전 업데이트를 위해 매니페스트 파일을 편집할 때 다음과 같이 여러 가지 잠재적인 버전 관리 전략을 사용합니다.
옵션 | 작업 |
---|---|
auto | 앱과 라이브러리를 구분하려고 합니다. 앱에는 increase , 라이브러리에는 widen 을 사용합니다. |
increase | 항상 새 버전과 일치하도록 최소 버전 요구 사항을 증가시킵니다. 범위가 이미 존재하는 경우 일반적으로 하한만 증가시킵니다. |
increase-if-necessary | 원래 제약 조건이 새 버전을 허용하는 경우 제약 조건을 그대로 두고, 그렇지 않으면 제약 조건을 범프합니다. |
lockfile-only | 잠금 파일을 업데이트하기 위한 끌어오기 요청만 만듭니다. 패키지 매니페스트 변경이 필요한 새 버전은 무시합니다. |
widen | 가능하면 새 버전과 이전 버전을 모두 포함하도록 버전 요구 사항을 확장합니다. 이렇게 하면 일반적으로 허용되는 최대 버전 요구 사항만 증가합니다. |
해당 없음 | 일부 패키지 관리자는 아직 versioning-strategy 매개 변수 구성을 지원하지 않습니다. |
다음 표는 versioning-strategy
를 사용하는 방법의 예시를 보여 줍니다.
현재 제약 조건 | 현재 버전 | 새 버전 | 전략 | 새 제약 조건 |
---|---|---|---|---|
^1.0.0 | 1.0.0 | 1.2.0 | widen | ^1.0.0 |
^1.0.0 | 1.0.0 | 1.2.0 | increase | ^1.2.0 |
^1.0.0 | 1.0.0 | 1.2.0 | increase-if-necessary | ^1.0.0 |
^1.0.0 | 1.0.0 | 2.0.0 | widen | >=1.0.0 <3.0.0 |
^1.0.0 | 1.0.0 | 2.0.0 | increase | ^2.0.0 |
^1.0.0 | 1.0.0 | 2.0.0 | increase-if-necessary | ^2.0.0 |
지원되는 패키지 관리자에 대해 이 동작을 변경하려면 versioning-strategy
옵션을 사용합니다.
기본이 아닌 분기에서 버전 업데이트를 확인하는 데 target-branch
를 사용하지 않는 한 이 옵션을 설정하면 이 패키지 관리자의 매니페스트 파일에 대한 보안 업데이트 끌어오기 요청에도 영향을 줍니다.
사용 가능한 업데이트 전략:
에코시스템 | 지원되는 버전 관리 전략 | 기본 전략 |
---|---|---|
bundler | auto , increase , increase-if-necessary , lockfile-only | auto |
cargo | auto , lockfile-only | auto |
composer | auto , increase , increase-if-necessary , lockfile-only , widen | auto |
docker | 해당 없음 | 해당 없음 |
github-actions | 해당 없음 | 해당 없음 |
gitsubmodule | 해당 없음 | 해당 없음 |
gomod | 해당 없음 | 해당 없음 |
gradle | 해당 없음 | 해당 없음 |
maven | 해당 없음 | 해당 없음 |
mix | auto , lockfile-only | auto |
npm | auto , increase , increase-if-necessary , lockfile-only , widen | auto |
nuget | 해당 없음 | 해당 없음 |
pip | auto , increase , increase-if-necessary , lockfile-only | auto |
pub | auto , increase , increase-if-necessary , widen | auto |
terraform | 해당 없음 | 해당 없음 |
참고: N/A
는 패키지 관리자가 아직 versioning-strategy
매개 변수 구성을 지원하지 않음을 나타냅니다. 전략 코드는 오픈 소스이므로 특정 에코시스템이 새 전략을 지원하도록 하려면 언제든지 https://github.com/dependabot/dependabot-core/에 끌어오기 요청을 제출할 수 있습니다.
# Example configuration for customizing the manifest version strategy
version: 2
updates:
- package-ecosystem: "composer"
directory: "/"
schedule:
interval: "weekly"
# Increase the version requirements for Composer only when required
versioning-strategy: increase-if-necessary
프라이빗 레지스트리에 대한 구성 옵션
최상위 registries
키는 선택 사항입니다. 따라서 Dependabot이 프라이빗 패키지 레지스트리에 액세스하는 데 사용할 수 있는 인증 세부 정보를 지정할 수 있습니다.
Dependabot에 GitLab 또는 Bitbucket이 호스스팅하는 프라이빗 패키지 레지스트리에 대한 액세스를 부여하려면 type
/git
을(를) 지정하면 됩니다. 자세한 내용은 git
를 참조하세요.
참고: 프라이빗 네트워크의 방화벽 뒤에 있는 프라이빗 레지스트리는 지원되지 않습니다.
- Bundler
- Docker
- Gradle
- Maven
- Npm
- Nuget
- Python
- Yarn
registries
키의 값은 결합형 배열이며, 각 요소는 특정 레지스트리를 식별하는 키와 해당 레지스트리에 액세스하는 데 필요한 설정을 지정하는 결합형 배열 값으로 구성됩니다. 다음 dependabot.yml
파일은 파일의 registries
섹션에 dockerhub
로 식별된 레지스트리를 구성한 다음, 파일의 updates
섹션에서 이를 참조합니다.
# Minimal settings to update dependencies in one private registry
version: 2
registries:
dockerhub: # Define access for a private registry
type: docker-registry
url: registry.hub.docker.com
username: octocat
password: ${{secrets.DOCKERHUB_PASSWORD}}
updates:
- package-ecosystem: "docker"
directory: "/docker-registry/dockerhub"
registries:
- dockerhub # Allow version updates for dependencies in this registry
schedule:
interval: "monthly"
다음 옵션을 사용하여 액세스 설정을 지정합니다. 레지스트리 설정은 type
과 url
을 포함해야 하며, 일반적으로 username
및 password
조합이나 token
을 포함해야 합니다.
옵션 | 설명 |
---|---|
type | 레지스트리의 형식을 식별합니다. 사용 가능한 레지스트리 유형에 대한 자세한 내용은 "registries "에서 확인할 수 있습니다. 비공개 레지스트리의 구성에 대한 자세한 내용은 "비공개 레지스트리의 구성 옵션"을 참조하세요. |
url | 이 레지스트리의 종속성에 액세스하는 데 사용할 URL입니다. 프로토콜은 선택 사항입니다. 지정하지 않으면 https:// 가 가정됩니다. Dependabot은 필요에 따라 후행 슬래시를 추가하거나 무시합니다. |
username | Dependabot이 레지스트리에 액세스하는 데 사용하는 사용자 이름입니다.username 은 계정의 사용자 이름 또는 이메일 주소입니다. |
password | 지정된 사용자의 암호를 포함하는 Dependabot 비밀에 대한 참조입니다. 자세한 내용은 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요.password 는 사용자 이름별로 지정된 계정에 대한 암호입니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다. |
key | 이 레지스트리의 액세스 키가 포함된 Dependabot 비밀에 대한 참조입니다. 자세한 내용은 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요. |
token | 이 레지스트리의 액세스 토큰이 포함된 Dependabot 비밀에 대한 참조입니다. 자세한 내용은 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요.token 은 외부 시스템에 대한 액세스 토큰을 제공하는 데 사용되며 GitHub personal access token을(를) 제공하는 데 사용하면 안 됩니다. GitHub personal access token을(를) 사용하려면 암호로 제공해야 합니다. |
replaces-base | 레지스트리의 경우 부울 값이true 인 경우 Dependabot은(는) 특정 에코시스템의 기본 URL이 아닌 지정된 URL을 사용하여 종속성을 해결합니다. 예를 들어, type: python-index 인 레지스트리의 경우 부울 값이 true 이면 pip는 Python 패키지 인덱스의 기준 URL(기본적으로 https://pypi.org/simple )이 아닌 지정된 URL을 사용하여 종속성을 확인합니다. |
지정하는 각 구성 type
에 필요한 설정을 제공해야 합니다. 일부 유형은 두 가지 이상의 연결 방법을 허용합니다. 다음 섹션에서는 각 type
에 사용해야 하는 설정의 세부 정보를 제공합니다.
비공개 레지스트리를 구성할 때 참고할 권장 사항과 조언, 사용 가능한 옵션에 대한 심층적인 내용은 "Dependabot의 개인 레지스트리 구성에 대한 지침"을(를) 참조하세요.
composer-repository
composer-repository
유형은 사용자 이름 및 암호를 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
composer:
type: composer-repository
url: https://repo.packagist.com/example-company/
username: octocat
password: ${{secrets.MY_PACKAGIST_PASSWORD}}
docker-registry
Dependabot은 OCI 컨테이너 레지스트리 사양을 구현하는 모든 컨테이너 레지스트리에서 작동합니다. 자세한 내용은 https://github.com/opencontainers/distribution-spec/blob/main/spec.md 페이지를 참조하세요. Dependabot은 중앙 토큰 서비스 또는 HTTP 기본 인증을 통해 프라이빗 레지스트리에 대한 인증을 지원합니다. 자세한 내용은 Docker 설명서의 토큰 인증 사양 및 Wikipedia의 기본 액세스 인증을 참조하세요.
docker-registry
유형은 사용자 이름 및 암호를 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
dockerhub:
type: docker-registry
url: https://registry.hub.docker.com
username: octocat
password: ${{secrets.MY_DOCKERHUB_PASSWORD}}
replaces-base: true
docker-registry
유형을 통해 정적 AWS 자격 증명을 사용하여 프라이빗 Amazon ECR에서 끌어올 수도 있습니다.
registries:
ecr-docker:
type: docker-registry
url: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
username: ${{secrets.ECR_AWS_ACCESS_KEY_ID}}
password: ${{secrets.ECR_AWS_SECRET_ACCESS_KEY}}
replaces-base: true
git
git
유형은 사용자 이름 및 암호를 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
registries:
github-octocat:
type: git
url: https://github.com
username: x-access-token
password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
hex-organization
hex-organization
유형은 조직 및 키를 지원합니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
github-hex-org:
type: hex-organization
organization: github
key: ${{secrets.MY_HEX_ORGANIZATION_KEY}}
hex-repository
hex-repository
형식은 인증 키를 지원합니다.
repo
는 필수 필드이며, 종속성 선언에 사용되는 리포지토리의 이름과 일치해야 합니다.
public-key-fingerprint
는 선택적 구성 필드로, 16진수 리포지토리에 대한 공개 키의 지문을 나타냅니다. public-key-fingerprint
는 16진수에서 프라이빗 리포지토리와의 트러스트를 설정하는 데 사용됩니다. public-key-fingerprint
필드는 일반 텍스트로 나열하거나 Dependabot 비밀로 저장할 수 있습니다.
registries:
github-hex-repository:
type: hex-repository
repo: private-repo
url: https://private-repo.example.com
auth-key: ${{secrets.MY_AUTH_KEY}}
public-key-fingerprint: ${{secrets.MY_PUBLIC_KEY_FINGERPRINT}}
maven-repository
maven-repository
유형은 사용자 이름 및 암호를 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
maven-artifactory:
type: maven-repository
url: https://acme.jfrog.io/artifactory/my-maven-registry
username: octocat
password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
npm-registry
npm-registry
유형은 사용자 이름 및 암호 또는 토큰을 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
사용자 이름 및 암호를 사용하는 경우 .npmrc
의 인증 토큰에 base64
로 인코드된 _password
가 포함될 수 있습니다. 그러나 Dependabot 구성 파일에서 참조된 암호는 원래(인코드되지 않은) 암호여야 합니다.
참고: npm.pkg.github.com
을 사용할 때는 경로를 포함하지 마세요. 대신 경로 없이 https://npm.pkg.github.com
URL을 사용합니다.
registries:
npm-npmjs:
type: npm-registry
url: https://registry.npmjs.org
username: octocat
password: ${{secrets.MY_NPM_PASSWORD}} # Must be an unencoded password
replaces-base: true
registries:
npm-github:
type: npm-registry
url: https://npm.pkg.github.com
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
replaces-base: true
보안상의 이유로 Dependabot은(는) 환경 변수를 설정하지 않습니다. Yarn(v2 이상)을 사용하려면 액세스하는 모든 환경 변수를 설정해야 합니다. .yarnrc.yml
파일에서 환경 변수에 액세스할 때는 ${ENV_VAR-fallback}
또는 ${ENV_VAR:-fallback}
과 같은 대체 값을 제공해야 합니다. 자세한 내용은 Yarn 설명서의 Yarnrc 파일을 참조하세요.
nuget-feed
nuget-feed
유형은 사용자 이름 및 암호 또는 토큰을 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
registries:
nuget-example:
type: nuget-feed
url: https://nuget.example.com/v3/index.json
username: octocat@example.com
password: ${{secrets.MY_NUGET_PASSWORD}}
registries:
nuget-azure-devops:
type: nuget-feed
url: https://pkgs.dev.azure.com/.../_packaging/My_Feed/nuget/v3/index.json
username: octocat@example.com
password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
python-index
python-index
유형은 사용자 이름 및 암호 또는 토큰을 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
python-example:
type: python-index
url: https://example.com/_packaging/my-feed/pypi/example
username: octocat
password: ${{secrets.MY_BASIC_AUTH_PASSWORD}}
replaces-base: true
registries:
python-azure:
type: python-index
url: https://pkgs.dev.azure.com/octocat/_packaging/my-feed/pypi/example
username: octocat@example.com
password: ${{secrets.MY_AZURE_DEVOPS_TOKEN}}
replaces-base: true
rubygems-server
rubygems-server
유형은 사용자 이름 및 암호 또는 토큰을 지원합니다. 계정이 GitHub 계정인 경우 암호 대신 GitHub personal access token을(를) 사용할 수 있습니다.
이 레지스트리 유형은 url
옵션에 제공된 경로와 접두사가 일치합니다. 즉, 동일한 호스트에 여러 자격 증명을 제공할 수 있으며, 이 자격 증명은 고유 경로에 액세스하는 데 사용할 수 있습니다. 그러나 동일한 호스트에 여러 레지스트리가 없는 경우 레지스트리의 모든 경로가 자격 증명을 받도록 url
에서 경로를 생략하는 것이 좋습니다.
registries:
ruby-example:
type: rubygems-server
url: https://rubygems.example.com
username: octocat@example.com
password: ${{secrets.MY_RUBYGEMS_PASSWORD}}
replaces-base: true
registries:
ruby-github:
type: rubygems-server
url: https://rubygems.pkg.github.com/octocat/github_api
token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}
replaces-base: true
terraform-registry
terraform-registry
유형은 토큰을 지원합니다.
registries:
terraform-example:
type: terraform-registry
url: https://terraform.example.com
token: ${{secrets.MY_TERRAFORM_API_TOKEN}}
베타 수준 에코시스템에 대한 지원 활성화
enable-beta-ecosystems
기본적으로 Dependabot은 완전히 지원되는 에코시스템에 대해서만 종속성 매니페스트 및 잠금 파일을 업데이트합니다. 아직 일반 공급되지 않은 에코시스템의 업데이트를 옵트인하려면 enable-beta-ecosystems
플래그를 사용합니다.
현재 베타에 에코시스템이 없습니다.
# Configure 베타 ecosystem
version: 2
enable-beta-ecosystems: true
updates:
- package-ecosystem: "beta-ecosystem"
directory: "/"
schedule:
interval: "weekly"