Note
사이트 관리자가 먼저 GitHub Enterprise Server 인스턴스의 Dependabot updates를 설정해야 이 기능을 사용할 수 있습니다. 자세한 내용은 "엔터프라이즈에 Dependabot 사용"을(를) 참조하세요.
엔터프라이즈 소유자가 엔터프라이즈 수준에서 정책을 설정한 경우 Dependabot updates를 사용하거나 사용하지 않도록 설정하지 못할 수 있습니다. 자세한 내용은 "엔터프라이즈에 대한 코드 보안 및 분석을 위한 정책 적용"을(를) 참조하세요.
About Dependabot errors
Dependabot은 종속성을 업데이트하기 위한 끌어오기 요청을 발생시킵니다. 리포지토리가 구성된 방식에 따라 Dependabot은 버전 업데이트 및/또는 보안 업데이트를 위한 끌어오기 요청을 발생시키기도 합니다. 이러한 끌어오기 요청은 다른 끌어오기 요청과 동일한 방식으로 관리하지만 몇 가지 추가 명령을 사용할 수 있습니다. Dependabot 종속성 업데이트 사용에 대한 자세한 내용은 "Dependabot 보안 업데이트 구성." 및 "Dependabot 버전 업데이트 구성"을 참조하세요.
If anything prevents Dependabot from raising a pull request, this is reported as an error.
Note
Dependabot doesn't create pull requests for inactive repositories. For information about inactivity criteria, see Dependabot 보안 업데이트 정보 and Dependabot 버전 업데이트 정보, for security and version updates, respectively.
Investigating errors with Dependabot security updates
When Dependabot is blocked from creating a pull request to fix a Dependabot alert, it posts the error message on the alert. The Dependabot alerts view shows a list of any alerts that have not been resolved yet. To access the alerts view, click Dependabot alerts on the Security tab for the repository. Where a pull request that will fix the vulnerable dependency has been generated, the alert includes a link to that pull request.
There are several reasons why an alert may have no pull request link:
- Dependabot security updates are not enabled for the repository.
- The alert is for an indirect or transitive dependency that is not explicitly defined in a lock file.
- An error blocked Dependabot from creating a pull request.
If an error blocked Dependabot from creating a pull request, you can display details of the error by clicking the alert.
Investigating errors with Dependabot version updates
When Dependabot is blocked from creating a pull request to update a dependency in an ecosystem, you can view the job logs list to find out more about the error .
작업 로그 목록은 리포지토리의 종속성 그래프에서 액세스할 수 있습니다. 종속성 그래프에서 Dependabot 탭을 클릭한 다음 영향을 받는 매니페스트 파일의 오른쪽에 있는 최근 업데이트 작업을 클릭합니다.
To view the full logs files for a particular job, to the right of the log entry you are interested in, click view logs.
For more information, see Viewing Dependabot job logs.
Understanding Dependabot errors
Pull requests for security updates act to upgrade a vulnerable dependency to the minimum version that includes a fix for the vulnerability. In contrast, pull requests for version updates act to upgrade a dependency to the latest version allowed by the package manifest and Dependabot configuration files. Consequently, some errors are specific to one type of update.
Dependabot cannot update DEPENDENCY to a non-vulnerable version
Security updates only. Dependabot cannot create a pull request to update the vulnerable dependency to a secure version without breaking other dependencies in the dependency graph for this repository.
Every application that has dependencies has a dependency graph, that is, a directed acyclic graph of every package version that the application directly or indirectly depends on. Every time a dependency is updated, this graph must resolve otherwise the application won't build. When an ecosystem has a deep and complex dependency graph, for example, npm and RubyGems, it is often impossible to upgrade a single dependency without upgrading the whole ecosystem.
The best way to avoid this problem is to stay up to date with the most recently released versions, for example, by enabling version updates. This increases the likelihood that a vulnerability in one dependency can be resolved by a simple upgrade that doesn't break the dependency graph. For more information, see Dependabot 버전 업데이트 구성.
Dependabot tries to update dependencies without an alert
Security updates only. Dependabot updates explicitly defined transitive dependencies that are vulnerable for all ecosystems. For npm, Dependabot will raise a pull request that also updates the parent dependency if it's the only way to fix the transitive dependency.
For example, a project with a dependency on A
version ~2.0.0
which has a transitive dependency on B
version ~1.0.0
which has resolved to 1.0.1
.
my project
|
--> A (2.0.0) [~2.0.0]
|
--> B (1.0.1) [~1.0.0]
If a security vulnerability is released for B
versions <2.0.0
and a patch is available at 2.0.0
then Dependabot will attempt to update B
but will find that it's not possible due to the restriction in place by A
which only allows lower vulnerable versions. To fix the vulnerability, Dependabot will look for updates to dependency A
which allow the fixed version of B
to be used.
Dependabot automatically generates a pull request that upgrades both the locked parent and child transitive dependencies.
Dependabot fails to close a open pull request for an update that has already been applied on the default branch
Dependabot will close pull requests for dependency updates, once it detects these updates have been committed to the default branch. However, in rare circumstances, the pull request may remain open. If you notice that you have committed an update to a dependency manually, and that the pull request for that same update is still open, you can use one of the following commands in a comment on the pull request:
@dependabot recreate
, or@dependabot rebase
.
Either comment will trigger Dependabot to check if the dependency is no longer upgradable or vulnerable. If Dependabot detects that the pull request is no longer required, it will close the pull request in this particular case.
For more information about Dependabot comment commands, see 종속성 업데이트에 대한 끌어오기 요청 관리.
Dependabot cannot update to the required version as there is already an open pull request for the latest version
Security updates only. Dependabot will not create a pull request to update the vulnerable dependency to a secure version because there is already an open pull request to update this dependency. You will see this error when a vulnerability is detected in a single dependency and there's already an open pull request to update the dependency to the latest version.
There are two options: you can review the open pull request and merge it as soon as you are confident that the change is safe, or close that pull request and trigger a new security update pull request. For more information, see Triggering a Dependabot pull request manually.
No security update is needed as DEPENDENCY is no longer vulnerable
Security updates only. Dependabot cannot close a pull request to update a dependency that is not, or is no longer, vulnerable. You may see this error when dependency graph data is stale, or when the dependency graph and Dependabot do not agree if a particular version of a dependency is vulnerable.
To debug the problem, we recommend you first examine the dependency graph for your repository, review what version it has detected for the dependency, and check if the identified version matches what is being used in your repository.
If you suspect your dependency graph data is out of date, you may need to manually update the dependency graph for your repository or investigate your dependency information further. For more information, see 종속성 그래프 문제 해결.
If you are able to confirm the dependency version is no longer vulnerable, you can close the Dependabot pull request.
Dependabot timed out during its update
Dependabot took longer than the maximum time allowed to assess the update required and prepare a pull request. This error is usually seen only for large repositories with many manifest files, for example, npm or yarn monorepo projects with hundreds of package.json files. Updates to the Composer ecosystem also take longer to assess and may time out.
This error is difficult to address. If a version update times out, you could specify the most important dependencies to update using the allow
parameter or, alternatively, use the ignore
parameter to exclude some dependencies from updates. Updating your configuration might allow Dependabot to review the version update and generate the pull request in the time available.
If a security update times out, you can reduce the chances of this happening by keeping the dependencies updated, for example, by enabling version updates. For more information, see Dependabot 버전 업데이트 구성.
Dependabot cannot open any more pull requests
There's a limit on the number of open pull requests Dependabot will generate. When this limit is reached, no new pull requests are opened and this error is reported. The best way to resolve this error is to review and merge some of the open pull requests.
There are separate limits for security and version update pull requests, so that open version update pull requests cannot block the creation of a security update pull request. The limit for security update pull requests is 10. By default, the limit for version updates is 5 but you can change this using the open-pull-requests-limit
parameter in the configuration file. For more information, see Dependabot options reference.
The best way to resolve this error is to merge or close some of the existing pull requests and trigger a new pull request manually. For more information, see Triggering a Dependabot pull request manually.
Dependabot can't resolve or access your dependencies
If Dependabot attempts to check whether dependency references need to be updated in a repository, but can't access one or more of the referenced files, the operation will fail with the error message "Dependabot can't resolve your LANGUAGE dependency files." The API error type is git_dependencies_not_reachable
.
Similarly, if Dependabot can't access a private package registry in which a dependency is located, one of the following errors is generated:
- "Dependabot can't reach a dependency in a private package registry"
(API error type:private_source_not_reachable
) - "Dependabot can't authenticate to a private package registry"
(API error type:private_source_authentication_failure
) - "Dependabot timed out while waiting for a private package registry"
(API error type:private_source_timed_out
) - "Dependabot couldn't validate the certificate for a private package registry"
(API error type:private_source_certificate_failure
)
To allow Dependabot to update the dependency references successfully, make sure that all of the referenced dependencies are hosted at accessible locations.
Version updates only. 보안 또는 버전 업데이트를 실행할 때 일부 에코시스템은 원본의 모든 종속성을 확인하여 업데이트에 성공했는지 확인할 수 있어야 합니다. 매니페스트 또는 잠금 파일에 프라이빗 종속성이 포함된 경우 Dependabot은 해당 종속성이 호스트된 위치에 액세스할 수 있어야 합니다. 조직 소유자는 동일한 조직 내 프로젝트의 종속성이 포함된 프라이빗 리포지토리에 대한 액세스 권한을 Dependabot에 부여할 수 있습니다. 자세한 내용은 "조직의 보안 및 분석 설정 관리"을(를) 참조하세요. 리포지토리의 dependabot.yml
구성 파일에서 프라이빗 레지스트리에 대한 액세스를 구성할 수 있습니다. 자세한 내용은 "Dependabot options reference"을(를) 참조하세요. Additionally, Dependabot doesn't support private GitHub dependencies for all package managers. For more information, see Dependabot 지원 에코시스템 및 리포지토리.
Dependabot fails to group a set of dependencies into a single pull request for Dependabot version updates
The groups
configuration settings in the dependabot.yml
file can apply to version updates and security updates. Use the applies-to
key to specify where (version updates or security updates) a set of grouping rules is applied.
version 업데이트 및 security 업데이트 모두에 단일 그룹화 규칙 집합을 적용할 수 없습니다. 대신 동일한 조건을 사용하여 버전 업데이트와 보안 업데이트를 모두 그룹화하려면 별도로 명명된 두 개의 규칙 그룹화 집합을 정의해야 합니다.
When you configure grouped version updates, you must configure groups per package ecosystem. To debug the problem, we recommend you look at the logs. For information about accessing the logs for a manifest, see Investigating errors with Dependabot version updates above.
You may have unintentionally created empty groups. This happens, for example, when you set a dependency-type
in the allow
key for the overall job.
allow: dependency-type: production # this restricts the entire job to production dependencies groups: development-dependencies: dependency-type: "development" # this group will always be empty
allow:
dependency-type: production
# this restricts the entire job to production dependencies
groups:
development-dependencies:
dependency-type: "development"
# this group will always be empty
In this example, Dependabot will:
- Look at your dependency list and restrict the job to dependencies used in
production
only. - Try to create a group called
development-dependencies
which is a subset of this reduced list. - Work out that the
development-dependencies
group is empty as alldevelopment
dependencies were removed in step 1. - Individually update all the dependencies that are not in the group. As the group for dependencies in production is empty, Dependabot will ignore the group, and create a separate pull request for each dependency.
You need to ensure that configuration settings don't cancel each other, and update them appropriately in your configuration file.
For more information on how to configure groups for Dependabot version updates, see Dependabot options reference.
Dependabot fails to group a set of dependencies into a single pull request for Dependabot security updates
The groups
configuration settings in the dependabot.yml
file can apply to version updates and security updates. Use the applies-to
key to specify where (version updates or security updates) a set of grouping rules is applied. Check you have grouping configured to apply to security updates. If the applies-to
key is absent from a set of grouping rules in your configuration, any group rules will by default only apply to version updates.
version 업데이트 및 security 업데이트 모두에 단일 그룹화 규칙 집합을 적용할 수 없습니다. 대신 동일한 조건을 사용하여 버전 업데이트와 보안 업데이트를 모두 그룹화하려면 별도로 명명된 두 개의 규칙 그룹화 집합을 정의해야 합니다.
For grouped security updates, Dependabot uses the following guidelines to create grouped pull requests.
- Dependabot will group dependencies from the same package ecosystem that are located in different directories when grouping rules are specified for configurations that use the
directories
key. - Dependabot will apply other relevant customization options from the
dependabot.yml
file to pull requests for grouped security updates.dependabot.yml
파일에 구성된 그룹 규칙은 조직 또는 리포지토리 수준에서 그룹화된 보안 업데이트를 사용하거나 사용하지 않도록 설정하기 위한 사용자 인터페이스 설정을 재정의합니다. - Dependabot will not group dependencies from different package ecosystems together.
- Dependabot will not group security updates with version updates.
For more information, see Dependabot 보안 업데이트 정보 and Customizing pull requests for Dependabot security updates.
Dependabot fails to update one of the dependencies in a grouped pull request
There are different troubleshooting techniques you can use for failed version updates and failed security updates.
Handling failures in grouped version updates
Version updates only. Dependabot will show the failed update in your logs, as well as in the job summary at the end of your logs. You should use the @dependabot recreate
comment on the pull request to build the group again. For more information, see 종속성 업데이트에 대한 끌어오기 요청 관리.
If the dependency still fails to update, you should use the exclude-patterns
configuration so that the dependency is excluded from the group. Dependabot will then raise a separate pull request to update the dependency.
If the dependency still fails to update, there may be a problem with the dependency itself, or with Dependabot for that specific ecosystem.
종속성에 대한 업데이트를 무시하려면 다음 중 하나를 수행해야 합니다.
dependabot.yml
파일의 종속성에 대한ignore
규칙을 구성합니다. 자세한 내용은 "Dependabot options reference"을(를) 참조하세요.- 그룹화된 업데이트에 대한 끌어오기 요청의 종속성에
@dependabot ignore
메모 명령을 사용합니다. 자세한 내용은 "종속성 업데이트에 대한 끌어오기 요청 관리" 항목을 참조하세요.
Handling failures in grouped security updates
Security updates only. If a grouped pull request for security updates fails or is unable to be merged, we recommend you manually open pull requests to bump the versions of breaking changes. When you manually update a package that is included in a grouped pull request, Dependabot will rebase the pull request so it does not include the manually updated package.
종속성에 대한 업데이트를 무시하려면 다음 중 하나를 수행해야 합니다.
dependabot.yml
파일의 종속성에 대한ignore
규칙을 구성합니다. 자세한 내용은 "Dependabot options reference"을(를) 참조하세요.- 그룹화된 업데이트에 대한 끌어오기 요청의 종속성에
@dependabot ignore
메모 명령을 사용합니다. 자세한 내용은 "종속성 업데이트에 대한 끌어오기 요청 관리" 항목을 참조하세요.
Continuous integration (CI) fails on my grouped pull request
Version updates only. If the failure is due to a single dependency, you should use the exclude-patterns
configuration so that the dependency is excluded from the group. Dependabot will then raise a separate pull request to update the dependency.
종속성에 대한 업데이트를 무시하려면 다음 중 하나를 수행해야 합니다.
dependabot.yml
파일의 종속성에 대한ignore
규칙을 구성합니다. 자세한 내용은 "Dependabot options reference"을(를) 참조하세요.- 그룹화된 업데이트에 대한 끌어오기 요청의 종속성에
@dependabot ignore
메모 명령을 사용합니다. 자세한 내용은 "종속성 업데이트에 대한 끌어오기 요청 관리" 항목을 참조하세요.
If you continue to see CI failures, you should remove the group configuration so that Dependabot reverts to raising individual pull requests for each dependency. Then, you should check and confirm that the update works correctly for each individual pull request.
Triggering a Dependabot pull request manually
If you unblock Dependabot, you can manually trigger a fresh attempt to create a pull request.
- Security updates: Display the Dependabot alert that shows the error you have fixed and click Create Dependabot security update.
- Version updates: On the Insights tab for the repository click Dependency graph, and then click the Dependabot tab. Click Last checked TIME ago to see the log file that Dependabot generated during the last check for version updates. Click Check for updates.