About the dependabot.yml
file
The dependabot.yml
file defines how Dependabot maintains dependencies using version updates. In addition, all options marked with a icon also change how Dependabot creates pull requests for security updates, except where target-branch
is used.
The Dependabot configuration file, dependabot.yml
, uses YAML syntax. If you're new to YAML and want to learn more, see Learn YAML in five minutes.
You must store this file in the .github
directory of your repository in the default branch. When you add or update the dependabot.yml
file, this triggers an immediate check for version updates. For more information and an example, see Configurando a versão das atualizações do Dependabot.
Note
Dependabot alerts are configured in the repository or organization "Settings" tab and not in the dependabot.yml
file, see Configurando alertas do Dependabot.
Required keys
Key | Location | Purpose |
---|---|---|
version | Top level | Dependabot configuration syntax to use. Always: 2 . |
updates | Top level | Section where you define each package-ecosystem to update. |
package-ecosystem | Under updates | Define a package manager to update. |
directory | Under each package-ecosystem entry | Define the location of the manifest or other definition files to update. |
schedule.interval | Under each package-ecosystem entry | Define whether to look for version updates: daily , weekly , or monthly . |
Optionally, you can also include a top-level registries
key to define access details for private registries, see Top-level registries
key.
# Basic `dependabot.yml` file with # minimum configuration for two package managers version: 2 updates: # Enable version updates for npm - package-ecosystem: "npm" # Look for `package.json` and `lock` files in the `root` directory directory: "/" # Check the npm registry for updates every day (weekdays) schedule: interval: "daily" # Enable version updates for Docker - package-ecosystem: "docker" # Look for a `Dockerfile` in the `root` directory directory: "/" # Check for updates once a week schedule: interval: "weekly"
# Basic `dependabot.yml` file with
# minimum configuration for two package managers
version: 2
updates:
# Enable version updates for npm
- package-ecosystem: "npm"
# Look for `package.json` and `lock` files in the `root` directory
directory: "/"
# Check the npm registry for updates every day (weekdays)
schedule:
interval: "daily"
# Enable version updates for Docker
- package-ecosystem: "docker"
# Look for a `Dockerfile` in the `root` directory
directory: "/"
# Check for updates once a week
schedule:
interval: "weekly"
For a real-world example of a dependabot.yml
file, see Dependabot's own configuration file.
allow
Use to define exactly which dependencies to maintain for a package ecosystem. Often used with the ignore
option. For examples, see Controlling which dependencies are updated by Dependabot.
Dependabot default behavior:
- All dependencies explicitly defined in a manifest are kept up to date by version updates.
- All dependencies defined in lock files with vulnerable dependencies are updated by security updates.
When allow
is specified Dependabot uses the following process:
-
Check for all explicitly allowed dependencies.
-
Then filter out any ignored dependencies or versions.
If a dependency is matched by an
allow
and anignore
statement, then it is ignored.
Parameters | Purpose |
---|---|
dependency-name | Allow updates for dependencies with matching names, optionally using * to match zero or more characters. |
dependency-type | Allow updates for dependencies of specific types. |
dependency-name
(allow
)
For most package managers, you should define a value that will match the dependency name specified in the lock or manifest file. A few systems have more complex requirements.
Package manager | Format required | Example |
---|---|---|
Gradle and Maven | groupId:artifactId | org.kohsuke:github-api |
Docker for image tags | The full name of the repository | For an image tag of <account ID>.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc , use base/foo/bar/ruby . |
dependency-type
(allow
)
Dependency types | Supported by package managers | Allow updates |
---|---|---|
direct | All | All explicitly defined dependencies. |
indirect | bundler , pip , composer , cargo , gomod | Dependencies of direct dependencies (also known as sub-dependencies, or transient dependencies). |
all | All | All explicitly defined dependencies. For bundler , pip , composer , cargo , gomod , also the dependencies of direct dependencies. |
production | bundler , composer , mix , maven , npm , pip (not all managers) | Only to dependencies defined by the package manager as production dependencies. |
development | bundler , composer , mix , maven , npm , pip (not all managers) | Only to dependencies defined by the package manager as development dependencies. |
assignees
Specify individual assignees for all pull requests raised for a package ecosystem. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- Pull requests are created without any assignees.
When assignees
is defined:
- All pull requests for version updates are created with the chosen assignees.
- All pull requests for security updates are created with the chosen assignees, unless
target-branch
defines updates to a non-default branch.
Assignees must have write access to the repository. For organization-owned repositories, organization members with read access are also valid assignees.
commit-message
Define the format for commit messages. Since the titles of pull requests are written based on commit messages, this setting also impacts the titles of pull requests. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- Commit messages follow similar patterns to those detected in the repository.
When commit-message
is defined:
- All commit messages follow the defined pattern.
- All commit messages follow the defined pattern, unless
target-branch
defines updates to a non-default branch.
Parameters | Purpose |
---|---|
prefix | Defines a prefix for all commit messages and pull request titles. |
prefix-development | On supported systems, defines a different prefix to use for commits that update dependencies in the Development dependency group. |
include | Follow the commit message prefix with additional information. |
Tip
When pull requests are raised for grouped updates, the branch name and pull request title are defined by the group IDENTIFIER
, see groups
.
prefix
- Used for all commit messages unless
prefix-development
is also defined. - Value can be up to 50 characters.
- Dependabot inserts a colon after the prefix before adding the main commit message when the value ends with a letter, number, closing parenthesis, or closing bracket.
- End the value with a whitespace character to stop a colon being added.
prefix-development
Supported by: bundler
, composer
, mix
, maven
, npm
, and pip
.
- Used only for commit messages that update dependencies in the Development dependency group.
- Otherwise, the parameter behaves exactly as the
prefix
parameter.
include
- Supports only the value
scope
- When defined any prefix is followed by the type of dependencies updated in the commit:
deps
ordeps-dev
.
directory
Required option. Use to define the location of the package manifests for each package manager (for example, the package.json or Gemfile). Without this information Dependabot cannot create pull requests for version updates. For examples, see Example dependabot.yml file.
- Define the directory relative to the root of the repository for most package managers.
- For GitHub Actions, use the value
/
. Dependabot will search the/.github/workflows
directory, as well as theaction.yml/action.yaml
file from the root directory.
If you need to use more than one block in the configuration file to define updates for a single target branch of an ecosystem, you must ensure that all values are unique and there is no overlap in directories defined.
enable-beta-ecosystems
Not currently in use.
groups
Define rules to create one or more sets of dependencies managed by a package manager, to group updates into fewer, targeted pull requests. For examples, see Optimizing the creation of pull requests for Dependabot version updates.
Dependabot default behavior:
- Open a single pull request for each dependency that needs to be updated to a newer version for version updates.
When groups
is used to define rules:
- All version updates for dependencies that match a rule are combined in a single pull request.
- If a dependency matches more than one rule, it's included in the first group that it matches.
- Any outdated dependencies that do not match a rule are updated in individual pull requests.
Parameters | Purpose |
---|---|
IDENTIFIER | Define an identifier for the group to use in branch names and pull request titles. This must start and end with a letter, and can contain letters, pipes | , underscores _ , or hyphens - . |
dependency-type | Limit the group to a type. Supported values: development or production . |
patterns | Define one or more patterns to include dependencies with matching names. |
exclude-patterns | Define one or more patterns to exclude dependencies from the group. |
update-types | Limit the group to one or more semantic versioning levels. Supported values: minor , patch , and major . |
dependency-type
(groups
)
Supported by: bundler
, composer
, mix
, maven
, npm
, and pip
.
By default, a group will include all types of dependencies.
- Use
development
to include only dependencies in the "Development dependency group". - Use
production
to include only dependencies in the "Production dependency group".
patterns
and exclude-patterns
(groups
)
Both options support using *
as a wild card to define matches with dependency names.
update-types
(groups
)
By default, a group will include updates for all semantic versions (SemVer). SemVer is an accepted standard for defining versions of software packages, in the form x.y.z
. Dependabot assumes that versions in this form are always major.minor.patch
.
- Use
patch
to include patch releases. - Use
minor
to include minor releases. - Use
major
to include major releases.
For examples, see Controlling which dependencies are updated by Dependabot.
ignore
Use with the allow
option to define exactly which dependencies to maintain for a package ecosystem. Dependabot checks for all allowed dependencies and then filters out any ignored dependencies or versions. So a dependency that is matched by both an allow and an ignore will be ignored. For examples, see Controlling which dependencies are updated by Dependabot.
Dependabot default behavior:
- All dependencies explicitly defined in a manifest are kept up to date by version updates.
- All dependencies defined in lock files with vulnerable dependencies are updated by security updates.
When ignore
is used Dependabot uses the following process:
-
Check for all explicitly allowed dependencies.
-
Then filter out any ignored dependencies or versions.
If a dependency is matched by an
allow
and anignore
statement, then it is ignored.
Parameters | Purpose |
---|---|
dependency-name | Ignore updates for dependencies with matching names, optionally using * to match zero or more characters. |
versions | Ignore specific versions or ranges of versions. |
update-types | Ignore updates to one or more semantic versioning levels. Supported values: sem-ver:minor , sem-ver:patch , and sem-ver:major . |
dependency-name
(ignore
)
For most package managers, you should define a value that will match the dependency name specified in the lock or manifest file. A few systems have more complex requirements.
Package manager | Format required | Example |
---|---|---|
Gradle and Maven | groupId:artifactId | org.kohsuke:github-api |
Docker for image tags | The full name of the repository | For an image tag of <account ID>.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc , use base/foo/bar/ruby . |
versions
(ignore
)
Use to ignore specific versions or ranges of versions. If you want to define a range, use the standard pattern for the package manager. For example:
- npm: use
^1.0.0
- Bundler: use
~> 2.0
- Docker: use Ruby version syntax
- NuGet: use
7.*
For examples, see Controlling which dependencies are updated by Dependabot.
update-types
(ignore
)
Specify which semantic versions (SemVer) to ignore. SemVer is an accepted standard for defining versions of software packages, in the form x.y.z
. Dependabot assumes that versions in this form are always major.minor.patch
.
- Use
patch
to include patch releases. - Use
minor
to include minor releases. - Use
major
to include major releases.
insecure-external-code-execution
Supported by: bundler
, mix
, and pip
.
Allow Dependabot to execute external code in the manifest during updates. For examples, see Allowing external code execution.
Dependabot default behavior:
- When you give Dependabot access to one or more registries, external code execution is automatically disabled to protect your code from compromised packages.
- Version updates may fail without the ability to execute code.
When you allow insecure-external-code-execution
:
- Dependabot will execute code in the manifest as part of the version update process.
- The code has access to only the package managers in the registries associated with that
updates
setting. There is no access allowed to any of the registries defined in the top levelregistries
configuration. - This should enable the update to succeed but also could allow a compromised package to steal credentials or gain access to configured registries.
Supported value: allow
.
labels
Specify your own labels for all pull requests raised for a package manager. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- All pull requests have a
dependencies
label. - If you define more than one package manager, an additional label for the ecosystem or language is added to each pull request. For example:
java
for Gradle updates andsubmodules
for git submodule updates. - Dependabot creates these default labels automatically, as necessary in your repository.
When labels
is defined:
- The labels specified are used instead of the default labels.
- If any of these labels is not defined in the repository, it is ignored.
- You can disable all labels, including the default labels, using
labels: [ ]
.
Se você definir essa opção, isso também afetará as solicitações de pull para atualizações de segurança nos arquivos de manifesto deste gerenciador de pacotes, a menos que você use target-branch
para verificar se há atualizações de versão em um branch não padrão.
milestone
Associate all pull requests raised for a package manager with a milestone. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- No milestones are used.
When milestone
is defined:
- All pull requests for the package manager are added to the milestone.
Supported value: the numeric identifier of a milestone.
Tip
If you view a milestone, the final part of the page URL, after milestone
, is the identifier. For example: https://github.com/<org>/<repo>/milestone/3
, see Exibir o andamento do seu marco.
open-pull-requests-limit
Change the limit on the maximum number of pull requests for version updates open at any time.
Dependabot default behavior:
- If five pull requests with version updates are open, no further pull requests are raised until some of those open requests are merged or closed.
- Security updates have a separate, internal limit of ten open pull requests which cannot be changed.
When open-pull-requests-limit
is defined:
- Dependabot opens pull requests up to the defined integer value.
- You can temporarily disable version updates for a package manager by setting this option to zero, see Disabling Dependabot version updates.
package-ecosystem
Required option. Define one package-ecosystem
element for each package manager that you want Dependabot to monitor for new versions. The repository must also contain a dependency manifest or lock file for each package manager, see Example dependabot.yml
file.
Package manager | YAML value | Supported versions |
---|---|---|
Bundler | bundler | v1, v2 |
Cargo | cargo | v1 |
Composer | composer | v1, v2 |
Docker | docker | v1 |
Hex | mix | v1 |
elm-package | elm | v0.19 |
git submodule | gitsubmodule | Not applicable |
GitHub Actions | github-actions | Not applicable |
Go modules | gomod | v1 |
Gradle | gradle | Not applicable |
Maven | maven | Not applicable |
npm | npm | v6, v7, v8, v9 |
NuGet | nuget | <= 4.8 |
pip | pip | v21.1.2 |
pip-compile | pip | 6.1.0 |
pipenv | pip | <= 2021-05-29 |
pnpm | npm | v7, v8 v9 (version updates only) |
poetry | pip | v1 |
pub | pub | v2 |
Swift | swift | v5 |
Terraform | terraform | >= 0.13, <= 1.8.x |
yarn | npm | v1, v2, v3 |
pull-request-branch-name.separator
Specify a separator to use when generating branch names. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- Generate branch names of the form:
dependabot/PACKAGE_MANAGER/DEPENDENCY
When pull-request-branch-name.separator
is defined:
- Use the specified character in place of
/
.
Supported values: "-"
, _
, /
Tip
The hyphen symbol must be escaped so it is not interpreted as starting an empty YAML list.
rebase-strategy
Disable automatic rebasing of pull requests raised by Dependabot.
Dependabot default behavior is to rebase open pull requests when Dependabot detects any changes to a version or security update pull request. Dependabot checks for changes when:
- Your schedule runs to check for version updates.
- You reopen a closed Dependabot pull request.
- You change the value of
target-branch
in the Dependabot configuration file, seetarget-branch
. - A Dependabot pull request is in conflict after a recent push to the target branch.
When rebase-strategy
is set to disabled
, Dependabot stops rebasing pull requests.
Note
Pull requests that were open before you disable rebasing will continue to be rebased until 30 days after they were opened. This affects all pull requests that have conflicts with the target branch and all pull requests for version updates.
registries
Configure access to private package registries to allow Dependabot to update a wider range of dependencies, see Configurando o acesso a registros privados para Dependabot and Diretrizes para a configuração de registros privados para o Dependabot.
There are 2 locations in the dependabot.yml
file where you can use the registries
key:
- At the top level, where you define the private registries you want to use and their access information, see Configurando o acesso a registros privados para Dependabot.
- Within the
updates
blocks, where you can specify which private registries each package manager should use.
Dependabot default behavior is to raise pull requests only to update dependencies stored in publicly accessible registries.
When the Dependabot configuration file has a top-level registries
section, defining access to one or more private registries, you can configure each package-ecosystem
to use one or more of these private registries.
When registries
is defined for a package manager:
- Each private registry specified for a package manager is checked for version and security updates.
- Dependabot uses the access details defined in the top-level
registries
section.
Supported values: REGISTRY_NAME
or "*"
reviewers
Specify individual reviewers, or teams of reviewers, for all pull requests raised for a package manager. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- Pull requests are created without any reviewers assigned.
When reviewers
is defined:
- All pull requests for version updates are created with the chosen reviewers.
- All pull requests for security updates are created with the chosen reviewers, unless
target-branch
defines updates to a non-default branch.
Reviewers must have at least read access to the repository.
schedule
Required option. Define how often to check for new versions for each package manager you configure using the interval
parameter. Optionally, for daily and weekly intervals, you can customize when Dependabot checks for updates. For examples, see Optimizing the creation of pull requests for Dependabot version updates.
Parameters | Purpose |
---|---|
interval | Required. Defines the frequency for Dependabot. |
day | Specify the day to run for a weekly interval. |
time | Specify the time to run. |
timezone | Specify the timezone of the time value. |
interval
Supported values: daily
, weekly
, or monthly
Each package manager must define a schedule interval.
- Use
daily
to run on every weekday, Monday to Friday. - Use
weekly
to run once a week, by default on Monday. - Use
monthly
to run on the first day of each month.
By default, Dependabot randomly assigns a time to apply all the updates in the configuration file. You can use the time
and timezone
parameters to set a specific runtime for all intervals.
day
Supported values: monday
, tuesday
, wednesday
, thursday
, friday
, saturday
, or sunday
Optionally, run weekly updates for a package manager on a specific day of the week.
time
Format: hh:mm
Optionally, run all updates for a package manager at a specific time of day. By default, times are interpreted as UTC.
timezone
Specify a time zone for the time
value.
The time zone identifier must match a timezone in the database maintained by iana, see List of tz database time zones.
target-branch
Define a specific branch to check for version updates and to target pull requests for version updates against. For examples, see Customizing Dependabot pull requests to fit your processes.
Dependabot default behavior:
- Dependabot uses the default branch for the repository, see About the default branch.
When target-branch
is defined:
- Only manifest files on the target branch are checked for version updates.
- All pull requests for version updates are opened targetting the specified branch.
- Options defined for this
package-ecosystem
no longer apply to security updates because security updates always use the default branch for the repository.
vendor
Supported by: bundler
and gomod
only.
Tell Dependabot to maintain your vendored dependencies as well as the dependencies defined by manifest files. A dependency is described as "vendored" or "cached" when you store the code within your repository, see bundle cache
documentation and go mod vendor
documentation.
For examples, see Controlling which dependencies are updated by Dependabot.
Dependabot default behavior:
- Maintain only dependencies recorded in the manifest and lock files identified for Bundler.
- Raise security and version update pull requests that update the version numbers recorded in the manifest and lock files.
- For Go modules, any vendored dependencies are automatically identified and maintained as if
vendor
was enabled.
When vendor
is enabled:
- Dependabot also maintains dependencies for Bundler that are stored in the
_vendor/cache_
directory in the repository. - Pull requests will sometimes contain updates to a dependency that is stored in the repository.
Supported values: true
or false
versioning-strategy
Supported by: bundler
, cargo
, composer
, mix
, npm
, pip
, pub
Define how Dependabot should edit manifest files. For examples, see Controlling which dependencies are updated by Dependabot.
Dependabot default behavior:
- Try to differentiate between app and library dependencies.
- For apps, always increase the minimum version requirement to match the new version. The
increase
strategy. - For libraries, widen the allowed version requirements to include both the new and old versions, when possible. The
widen
strategy.
When versioning-strategy
is defined, Dependabot uses the strategy specified.
Value | Behavior |
---|---|
auto | Default behavior. |
increase | Always increase the minimum version requirement to match the new version. If a range already exists, typically this only increases the lower bound. |
increase-if-necessary | Leave the constraint if the original constraint allows the new version, otherwise, bump the constraint. |
lockfile-only | Only create pull requests to update lockfiles. Ignore any new versions that would require package manifest changes. |
widen | Widen the allowed version requirements to include both the new and old versions, when possible. Typically, this only increases the maximum allowed version requirement. |
For example, if the current version is 1.0.0
and the current constraint is ^1.0.0
the different strategies would raise the following updates:
New version 1.2.0
increase
: new constraint^1.2.0
increase-if-necessary
: new constraint^1.0.0
widen
: new constraint^1.0.0
New version 2.0.0
increase
: new constraint^2.0.0
increase-if-necessary
: new constraint^2.0.0
widen
: new constraint>=1.0.0 <3.0.0
Note
If the package manager you use does not yet support configuring the versioning-strategy
parameter, or does not support a value you need. The strategy code is open source, so if you'd like a particular ecosystem to support a new strategy, you are always welcome to submit a pull request in https://github.com/dependabot/dependabot-core/.
Top-level registries
key
Specify authentication details that Dependabot can use to access private package registries, including registries hosted by GitLab or Bitbucket.
Note
Private registries behind firewalls on private networks are supported for the following ecosystems:
- Bundler
- Docker
- Gradle
- Maven
- Npm
- NuGet
- Python
- Yarn
The value of the registries
key is an associative array, each element of which consists of a key that identifies a particular registry and a value which is an associative array that specifies the settings required to access that registry. The following dependabot.yml
file configures a registry identified as dockerhub
in the registries
section of the file and then references this in the updates
section of the file.
# Minimal settings to update dependencies stored 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"
# Minimal settings to update dependencies stored 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"
Você utiliza as seguintes opções para especificar as configurações de acesso. As configurações do registro precisam conter um type
e uma url
e, normalmente, uma combinação de username
e password
ou um token
.
Opção | Descrição |
---|---|
type | Identifica o tipo de registro. Para obter mais informações sobre os tipos de registro disponíveis, consulte "registries ". Para obter mais detalhes sobre a configuração de registros privados especificamente, consulte "Opções de configuração para registros privados". |
url | A URL a ser usada para acessar as dependências deste registro. O protocolo é opcional. Se não for especificado, https:// é assumido. Dependabot adiciona ou ignora barras à direita, conforme necessário. |
username | O nome de usuário que Dependabot usa para acessar o registro.username é o nome de usuário ou endereço de e-mail da conta. |
password | Uma referência a um segredo de Dependabot que contém a senha para o usuário especificado. Para obter mais informações, confira "Configurando o acesso a registros privados para Dependabot".password é a senha da conta especificada pelo nome de usuário. Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha. |
key | Uma referência a um segredo de Dependabot que contém uma chave de acesso para este registro. Para obter mais informações, confira "Configurando o acesso a registros privados para Dependabot". |
token | Uma referência a um segredo de Dependabot que contém um token de acesso para este registro. Para obter mais informações, confira "Configurando o acesso a registros privados para Dependabot".token é usado para fornecer um token de acesso para um sistema externo e não deve ser usado para fornecer um GitHub personal access token. Caso queira usar um GitHub personal access token, você deverá fornecê-lo como uma senha. |
replaces-base | Para registros, se o valor booliano for true , Dependabot resolverá dependências usando a URL especificada em vez da URL base desse ecossistema específico. Por exemplo, para registros com type: python-index , se o valor booliano é true , o Pip resolve as dependências usando a URL especificada em vez da URL base do Índice de Pacote Python (por padrão, https://pypi.org/simple ). |
Para obter informações detalhadas sobre as opções disponíveis, bem como recomendações e conselhos ao configurar registros privados, consulte "Diretrizes para a configuração de registros privados para o Dependabot".
type
and authentication details
The parameters used to provide authentication details for access to a private registry vary according to the registry type
.
Registry type | Required authentication parameters |
---|---|
composer-repository | username and password |
docker-registry | username and password |
git | username and password |
hex-organization | organization and key |
hex-repository | repo and auth-key optionally with the corresponding public-key-fingerprint |
maven-repository | username and password |
npm-registry | username and password or token |
nuget-feed | username and password or token |
pub-registry | token |
python-index | username and password or token |
rubygems-server | username and password or token |
terraform-registry | token |
All sensitive data used for authentication should be stored securely and referenced from that secure location, see Configurando o acesso a registros privados para Dependabot.
Tip
Se a conta for uma conta GitHub, você poderá usar um GitHub personal access token no lugar da senha.
url
and replaces-base
The url
parameter defines where to access a registry. When the optional replaces-base
parameter is enabled (true
), Dependabot resolves dependencies using the value of url
rather than the base URL of that specific ecosystem.