{"meta":{"title":"Referencia de opciones de Dependabot","intro":"Información detallada para todas las opciones que puede usar para personalizar cómo Dependabot mantiene los repositorios.","product":"Seguridad y calidad del código","breadcrumbs":[{"href":"/es/code-security","title":"Seguridad y calidad del código"},{"href":"/es/code-security/reference","title":"Referencia"},{"href":"/es/code-security/reference/supply-chain-security","title":"Seguridad de la cadena de suministro"},{"href":"/es/code-security/reference/supply-chain-security/dependabot-options-reference","title":"Opciones de Dependabot"}],"documentType":"article"},"body":"# Referencia de opciones de Dependabot\n\nInformación detallada para todas las opciones que puede usar para personalizar cómo Dependabot mantiene los repositorios.\n\nEn este artículo se proporciona información de referencia sobre las opciones de configuración disponibles en el `dependabot.yml` archivo . Use estas opciones para personalizar cómo Dependabot supervisa los ecosistemas de paquetes, programa las actualizaciones y crea solicitudes de incorporación de cambios. Para obtener información general sobre el `dependabot.yml` archivo y cómo funciona, consulte [Acerca del archivo dependabot.yml](/es/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file).\n\nTodas las opciones marcadas con un icono también cambian la forma en que Dependabot crea solicitudes de extracción para las actualizaciones de seguridad, excepto donde se usa `target-branch`.\n\n### Claves necesarias\n\n| Key | Ubicación | Propósito |\n| --------- | -------------- | --------- |\n| `version` | Nivel superior | |\n\n```\n Dependabot sintaxis de configuración a utilizar. Siempre: `2`|\n```\n\n\\| `updates` | Nivel superior| Sección en la que se define cada `package-ecosystem` que se va a actualizar.|\n\\| [`package-ecosystem`](#package-ecosystem-) | En `updates` | Define un administrador de paquetes que se va a actualizar. |\n\\| [\n`directories` o `directory`](#directories-or-directory--) | Debajo de cada entrada `package-ecosystem` | Definir la ubicación del manifiesto u otros archivos de definición para actualizar. |\n\\| [`schedule.interval`](#schedule-) | Debajo de cada entrada `package-ecosystem` | Defina si se deben buscar actualizaciones de versión: `daily`, , `weekly``monthly`, `quarterly`, `semiannually`, `yearly`o .`cron` |\n\nOpcionalmente, también puede incluir una clave `registries` de nivel superior para definir los detalles de acceso de los registros privados; consulte [Clave `registries` de nivel superior](#top-level-registries-key).\n\n```yaml copy\n\n# Basic `dependabot.yml` file with\n# minimum configuration for two package managers\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates every day (weekdays)\n schedule:\n interval: \"daily\"\n\n # Enable version updates for Docker\n - package-ecosystem: \"docker\"\n # Look for a `Dockerfile` in the `root` directory\n directory: \"/\"\n # Check for updates once a week\n schedule:\n interval: \"weekly\"\n```\n\nPara obtener un ejemplo real de un `dependabot.yml` archivo, consulte [Dependabotsu propio archivo de configuración](https://github.com/dependabot/dependabot-core/blob/main/.github/dependabot.yml).\n\n##\n\n```\n `allow`\n \n \n \n```\n\nSe usa para definir exactamente qué dependencias mantener para un ecosistema de paquetes. A menudo se usa con la opción [`ignore`](#ignore--). Para ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Todas las dependencias definidas explícitamente en un manifiesto se mantienen actualizadas por las actualizaciones de versión.\n* Las actualizaciones de seguridad actualizan todas las dependencias definidas en archivos de bloqueo con dependencias vulnerables.\n\nCuando `allow` se especifica, Dependabot se usa el siguiente proceso:\n\n1. Comprueba todas las dependencias **permitidas** explícitamente.\n2. Después, filtra las dependencias o versiones **omitidas**.\n\n Si una dependencia coincide con una instrucción `allow` y `ignore`, se **omite**.\n\n| Parámetros | Propósito |\n| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | Permitir actualizaciones de dependencias con nombres que coinciden; opcionalmente, se usa `*` para que coincida con cero o más caracteres. |\n| `dependency-type` | Permitir actualizaciones de dependencias de tipos específicos. |\n| | |\n| `update-types` | Permitir actualizaciones a uno o varios niveles de control de versiones semánticos. Valores admitidos: `version-update:semver-patch`, `version-update:semver-minor`y `version-update:semver-major`. |\n| | |\n\n###\n\n```\n `dependency-name` (`allow`)\n```\n\nPara la mayoría de los administradores de paquetes, debe definir un valor que coincida con el nombre de la dependencia especificado en el archivo de bloqueo o manifiesto. Algunos sistemas tienen requisitos más complejos.\n\n| Administrador de paquetes | Formato necesario | Example |\n| ------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |\n| Gradle y Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| Docker para etiquetas de imagen | El nombre completo del repositorio | Para una etiqueta de imagen de `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc`, use `base/foo/bar/ruby`. |\n\n###\n\n```\n `dependency-type` (`allow`)\n```\n\n| Tipos de dependencia | Administradores de paquete compatibles | Permitir actualizaciones |\n| -------------------- | -------------------------------------- | ------------------------------------------------ |\n| `direct` | Todos | Todas las dependencias definidas explícitamente. |\n| `indirect` | | |\n\n```\n `bundler`, `pip`, `composer`, `cargo`, , `gomod`, `uv` | Dependencias de dependencias directas (también conocidas como dependencias secundarias o dependencias transitivas).|\n```\n\n\\| `all` | Todos | Todas las dependencias definidas explícitamente. Para `bundler`, `pip`, `composer`, `cargo`, `gomod`, , `uv`, también las dependencias de las dependencias directas.|\n\\| `production` |\n`bundler`, `composer`, `mix`, `maven`, `npm`, , `pip`, `uv` (no todos los administradores) | Solo para dependencias definidas por el administrador de paquetes como dependencias de producción. |\n\\| `development`|\n`bundler`, `composer`, `mix`, `maven`, `npm`, , `pip`, `uv` (no todos los administradores) | Solo para dependencias definidas por el administrador de paquetes como dependencias de desarrollo. |\n\n###\n\n```\n `update-types` (`allow`)\n\n `update-types` solo afecta a las actualizaciones de _versión_ , no a _las actualizaciones de seguridad_.\n```\n\nEspecifique qué versiones semánticas (SemVer) se van a permitir.\n\nSemVer es un estándar aceptado para definir versiones de paquetes de software, con el formato `x.y.z`.\nDependabot supone que las versiones de este formulario siempre son `major.minor.patch`. El `update-types` valor es una lista de una o varias cadenas.\n\n* Use `version-update:semver-patch` para permitir versiones de parche.\n* Utilice `version-update:semver-minor` para permitir lanzamientos menores.\n* Use `version-update:semver-major` para permitir versiones principales.\n\nCuando `update-types` se omite de una `allow` regla, se permiten todos los tipos de actualización para esa regla.\n\nPuede combinar `update-types` con `dependency-name` o `dependency-type` para restringir aún más las actualizaciones permitidas. Para obtener ejemplos de cómo puede combinar estas opciones, consulte [Control de qué dependencias actualiza Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-semantic-versioning-levels-for-updates).\n\n##\n\n```\n `assignees`\n \n \n \n```\n\nEspecifique usuarios asignados individuales para todas las solicitudes de incorporación de cambios generadas para un ecosistema de paquetes. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Las solicitudes de incorporación cambios se crean sin usuarios asignados.\n\nCuando se define `assignees`:\n\n* Todas las solicitudes de pull para actualizaciones de versión se crean con los asignados elegidos.\n* Todas las solicitudes de tirada para actualizaciones de seguridad se crean con los cesionarios elegidos, a menos que `target-branch` definan actualizaciones en una rama no predeterminada.\n\nLos usuarios asignados deben tener acceso de escritura al repositorio. Para repositorios propiedad de la organización, los miembros de la organización con acceso de lectura también son usuarios asignados válidos.\n\n##\n\n```\n `commit-message`\n \n \n \n```\n\nDefina el formato para los mensajes de confirmación. Como los títulos de las solicitudes de incorporación de cambios se escriben en función de los mensajes de confirmación, este valor también afecta a los títulos de las solicitudes de incorporación de cambios. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Los mensajes de confirmación siguen patrones similares a los detectados en el repositorio.\n\nCuando se define `commit-message`:\n\n* Todos los mensajes de confirmación siguen el patrón definido.\n* Todos los mensajes de confirmación siguen el patrón definido, a menos que `target-branch` defina actualizaciones en una rama no predeterminada.\n\n| Parámetros | Propósito |\n| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `prefix` | Define un prefijo para todos los mensajes de confirmación y títulos de solicitud de incorporación de cambios. |\n| `prefix-development` | En los sistemas compatibles, define un prefijo diferente que se usará para confirmaciones que actualizan las dependencias en el grupo de dependencias de desarrollo. |\n| `include` | Después del prefijo del mensaje de confirmación debes agregar información adicional. |\n\n> \\[!TIP]\n> Cuando se generan solicitudes de incorporación de cambios para actualizaciones agrupadas, el nombre de rama y el título de la solicitud de incorporación de cambios se definen mediante el grupo `IDENTIFIER`; consulte [`groups`](#groups--).\n\n### `prefix`\n\n* Se usa para todos los mensajes de confirmación a menos que también se defina `prefix-development`.\n* El valor puede tener hasta 50 caracteres.\n* Dependabot inserta dos puntos después del prefijo antes de agregar el mensaje de confirmación principal cuando el valor termina con una letra, un número, un paréntesis de cierre o un corchete de cierre.\n* Finaliza el valor con un carácter de espacio en blanco para no agregar los dos puntos.\n\n### `prefix-development`\n\nCompatible con: `bundler`, , `composer``mix`, `maven`, `npm`, `pip`, y `uv`.\n\n* Solo se usa para los mensajes de confirmación que actualizan las dependencias del grupo de dependencias de desarrollo.\n* De lo contrario, el parámetro se comporta exactamente como el parámetro `prefix`.\n\n### `include`\n\n* Solo admite el valor `scope`\n* Cuando se define, cualquier prefijo va seguido del tipo de las dependencias actualizadas en la confirmación: `deps` o `deps-dev`.\n\n##\n\n```\n `cooldown`\n \n \n```\n\nDefine un **período de recuperación** para las actualizaciones de dependencias, lo que permite retrasar las actualizaciones durante un número configurable de días. La `cooldown` opción solo está disponible para las actualizaciones de *versión* , no para las actualizaciones de *seguridad* .\n\nEsta característica permite a los usuarios personalizar la frecuencia con Dependabot la que se generan nuevas actualizaciones de versiones, lo que ofrece un mayor control sobre la frecuencia de actualización. Para ejemplos, consulta [Optimización de la creación de pull requests para actualizaciones de Dependabot](/es/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates#setting-up-a-cooldown-period-for-dependency-updates).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Comprueba si hay actualizaciones según la programación definida a través de `schedule.interval`.\n* Tener en cuenta todas las nuevas versiones **inmediatamente** para las actualizaciones.\n\nCuando se define **`cooldown`**:\n\n1. ```\n Dependabot comprueba si hay actualizaciones según la configuración definida `schedule.interval` .\n ```\n2. ```\n Dependabot comprueba si hay alguna configuración de enfriamiento.\n ```\n3. Si la nueva versión de una dependencia se encuentra dentro de su período de tiempo de enfriamiento, Dependabot omite la actualización de la versión de esa dependencia.\n4. Las dependencias sin un período de tiempo de recuperación o los que han pasado su período de recuperación se actualizan a la versión más reciente según la configuración `versioning-strategy` configurada.\n5. Una vez que finaliza un intervalo de enfriamiento para una dependencia, Dependabot reanuda la actualización de la dependencia siguiendo la estrategia de actualización estándar definida en `dependabot.yml`.\n\n###\n\n```\n **Configuración de `cooldown`**\n```\n\nPuedes especificar la duración de la recuperación mediante las opciones siguientes.\n\n| Parámetro | Description |\n| -------------- | ----------- |\n| `default-days` | |\n\n```\n **Período de recuperación predeterminado para las dependencias** sin reglas específicas (opcional). |\n```\n\n\\| `semver-major-days` | Período de recuperación para **las actualizaciones de versiones principales** (opcional, solo se aplica a los administradores de paquetes que admiten SemVer). |\n\\| `semver-minor-days` | Período de recuperación para **las actualizaciones de versiones secundarias** (opcional, solo se aplica a los administradores de paquetes que admiten SemVer). |\n\\| `semver-patch-days` | Período de recuperación para **las actualizaciones de versión de revisión** (opcional, solo se aplica a los administradores de paquetes que admiten SemVer). |\n\\| `include` | Lista de dependencias **a las que se va a aplicar la recuperación** (hasta **150 elementos**). Admite caracteres comodín (`*`). |\n\\| `exclude` | Lista de dependencias **excluidas de la recuperación** (hasta **150 elementos**). Admite caracteres comodín (`*`). |\n\nEn la tabla siguiente se muestran los administradores de paquetes para los que se admite SemVer.\n\n| Administrador de paquetes | Compatible con SemVer |\n| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| | |\n| Bazel | |\n| | |\n| Bundler | |\n| Bun | |\n| Cargo | |\n| Composer | |\n| Devcontainers | |\n| Docker | |\n| Docker Compose | |\n| SDK de Dotnet | |\n| Elm | |\n| GitHub Actions | |\n| Gitsubmodule | |\n| Gomod (Módulos de Go) | |\n| Gradle | |\n| Helm | |\n| Hex (Hexadecimal) | |\n| | |\n| Julia | |\n| | |\n| Maven | |\n| NPM y Yarn | |\n| NuGet | |\n| | |\n| OpenTofu | |\n| | |\n| Pip | |\n| Pub | |\n| Swift | |\n| Terraform | |\n| UV | |\n\n> \\[!NOTE]\n>\n> * Si no se definen `semver-major-days` , `semver-minor-days` o `semver-patch-days`, la configuración `default-days` tendrá prioridad para las actualizaciones basadas en la actualización.\n> * La lista `exclude` siempre tiene prioridad sobre la lista `include`. Si se especifica una dependencia en ambas listas, se **excluye de la recuperación** y se actualizará inmediatamente.\n\n##\n\n```\n `directories` o `directory`\n\n **Opción obligatoria**. Se usa para definir la ubicación de los manifiestos de paquetes para cada administrador de paquetes (por ejemplo, _package.json_ o _Gemfile_). Sin esta información, Dependabot no puede crear pull requests para actualizaciones de versión. Para obtener ejemplos, consulta [Definición de varias ubicaciones para archivos de manifiesto](/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#defining-multiple-locations-for-manifest-files).\n```\n\n* Usa `directory` para definir un único directorio de manifiestos.\n\n* Usa `directories` para definir una lista de varios directorios de manifiestos.\n\n* Define directorios relativos a la raíz del repositorio para la mayoría de los administradores de paquetes.\n\n* Para GitHub Actions, use el valor `/`.\n Dependabot buscará en el `/.github/workflows` directorio, así como en el `action.yml/action.yaml` archivo desde el directorio raíz.\n\nSi necesitas usar más de un bloque en el archivo de configuración a fin de definir actualizaciones para una sola rama de destino de un ecosistema, debes asegurarte de que todos los valores sean únicos y que los directorios definidos no se superpongan.\n\n> \\[!NOTE]\n> La clave `directories` admite comodines y el carácter comodín `*`. Estas características no son compatibles con la clave `directory`.\n\n##\n\n```\n `enable-beta-ecosystems`\n \n \n```\n\nNo se usa actualmente.\n\n##\n\n```\n `groups`\n \n \n \n```\n\nDefine reglas para crear uno o varios conjuntos de dependencias administradas por un administrador de paquetes, para agrupar las actualizaciones en menos solicitudes de cambios dirigidas. Para ejemplos, consulta [Optimización de la creación de pull requests para actualizaciones de Dependabot](/es/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Abre una única solicitud de cambios para cada dependencia que se deba actualizar a una versión más reciente para las actualizaciones de versión y para las actualizaciones de seguridad.\n\nCuando se usa `groups` para definir reglas:\n\n* Todas las actualizaciones de las dependencias que coinciden con una regla se combinan en una única solicitud de incorporación de cambios.\n* Si una dependencia coincide con más de una regla, se incluye en el primer grupo que coincide.\n* Las dependencias obsoletas que no coinciden con una regla se actualizan en solicitudes de incorporación de cambios individuales.\n\n| Parámetros | Propósito |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `IDENTIFIER` | Definir un identificador para que el grupo lo use en nombres de rama y títulos de solicitud de incorporación de cambios. Debe empezar y acabar por una letra y puede tener letras, barras verticales `\\|`, guiones bajos `_` o guiones `-`. |\n| `applies-to` | Especifica a qué tipo de actualización se aplica el grupo. Cuando no se define, el valor predeterminado son las actualizaciones de versión. Valores admitidos: `version-updates` o `security-updates`. |\n| `dependency-type` | Limita el grupo a un tipo. Valores admitidos: `development` o `production`. |\n| `exclude-patterns` | Definir uno o varios patrones para excluir las dependencias del grupo. |\n| | |\n| `group-by` | Agrupa las actualizaciones entre varios directorios. Valor admitido: `dependency-name`. |\n| | |\n| `patterns` | Definir uno o varios patrones para incluir dependencias con nombres coincidentes. |\n| `update-types` | Limitar el grupo a uno o varios niveles de versionamiento semántico. Valores admitidos: `minor`, `patch`y `major`. |\n\n###\n\n```\n `dependency-type` (`groups`)\n```\n\nCompatible con: `bundler`, `composer`, `mix`, `maven`, `npm` y `pip`.\n\nDe manera predeterminada, un grupo incluirá todos los tipos de dependencias.\n\n* Usa `development` para incluir solo las dependencias en el \"Grupo de dependencias de desarrollo\".\n* Usa `production` para incluir solo las dependencias en el \"Grupo de dependencias de producción\".\n\n###\n\n```\n `group-by` (`groups`)\n```\n\nÚsase `groups..group-by` para especificar cómo Dependabot agrupar las actualizaciones en varios directorios en un monorepo.\n\n* **Tipo:** Cadena de caracteres\n* **Valores aceptados:**`dependency-name`\n* **Se aplica a:** Configuraciones con varios directorios especificados\n\nCuando se establece en `dependency-name`, Dependabot creará una única solicitud de incorporación de cambios para cada actualización de dependencia a través de todos los directorios especificados, en lugar de solicitudes de incorporación de cambios independientes por directorio.\n\n```\n **Limitaciones de la agrupación entre directorios**\n```\n\nCuando se usa `group-by: dependency-name`:\n\n* Todos los directorios deben usar el mismo ecosistema de paquetes (por ejemplo, todos `npm` o todos )`bundler`\n* Solo se aplica a **las actualizaciones de versión**\n* Si los directorios tienen restricciones de versión incompatibles para una dependencia, Dependabot creará solicitudes de incorporación de cambios independientes.\n\nPara ver ejemplos que muestran el uso de `group-by`, vea [Optimización de la creación de pull requests para actualizaciones de Dependabot](/es/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#grouping-updates-across-directories-in-a-monorepo).\n\n###\n\n```\n `patterns` y `exclude-patterns` (`groups`)\n```\n\nLas dos opciones admiten el uso de `*` como comodín para definir coincidencias con nombres de dependencia. Si una dependencia coincide con un patrón y un patrón de exclusión, se excluye del grupo.\n\n###\n\n```\n `update-types` (`groups`)\n```\n\nDe manera predeterminada, un grupo incluirá actualizaciones para todas las versiones semánticas (SemVer). SemVer es un estándar aceptado para definir versiones de paquetes de software, con el formato `x.y.z`. Dependabot supone que las versiones con este formato siempre son `major.minor.patch`.\n\n* Usa `patch` para incluir versiones de revisión.\n* Usa `minor` para incluir versiones secundarias.\n* Usa `major` para incluir versiones principales.\n\nPara ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore).\n\n##\n\n```\n `ignore`\n \n \n \n```\n\nSe usa con la opción [`allow`](#allow--) para definir exactamente qué dependencias mantener para un ecosistema de paquetes.\nDependabot comprueba todas las dependencias permitidas y, a continuación, filtra las dependencias o versiones omitidas. Por tanto, se omitirá una dependencia que coincida con permitir y omitir. Para ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#ignoring-specific-dependencies).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Todas las dependencias definidas explícitamente en un manifiesto se mantienen actualizadas por las actualizaciones de versión.\n* Las actualizaciones de seguridad actualizan todas las dependencias definidas en archivos de bloqueo con dependencias vulnerables.\n\nCuando `ignore` se usa usa Dependabot el siguiente proceso:\n\n1. Comprueba todas las dependencias **permitidas** explícitamente.\n2. Después, filtra las dependencias o versiones **omitidas**.\n\n Si una dependencia coincide con una instrucción `allow` y `ignore`, se **omite**.\n\n| Parámetros | Propósito |\n| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | Omitir actualizaciones de dependencias con nombres que coinciden; opcionalmente, se usa `*` para que coincida con cero o más caracteres. |\n| `versions` | Omitir versiones o rangos específicos de las versiones. |\n| `update-types` | Omitir las actualizaciones de uno o varios niveles de versionamiento semántico. Valores admitidos: `version-update:semver-patch`, `version-update:semver-minor`y `version-update:semver-major`. |\n\n###\n\n```\n `dependency-name` (`ignore`)\n```\n\nPara la mayoría de los administradores de paquetes, debe definir un valor que coincida con el nombre de la dependencia especificado en el archivo de bloqueo o manifiesto. Algunos sistemas tienen requisitos más complejos.\n\n| Administrador de paquetes | Formato necesario | Example |\n| ------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |\n| Gradle y Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| Docker para etiquetas de imagen | El nombre completo del repositorio | Para una etiqueta de imagen de `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc`, use `base/foo/bar/ruby`. |\n\n###\n\n```\n `versions` (`ignore`)\n```\n\nÚsala para omitir versiones concretas o intervalos de versiones. Si quieres definir un rango, usa el patrón estándar para el administrador de paquetes. Por ejemplo:\n\n* npm: utilizar `^1.0.0` \n* Bundler: usa `~> 2.0`\n* Docker: uso de la sintaxis de la versión de Bundler\n* NuGet: usa `7.*`\n* Maven: usar `[1.4,)`\n\nPara ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#ignoring-specific-versions-or-ranges-of-versions).\n\n###\n\n```\n `update-types` (`ignore`)\n```\n\nEspecifique qué versiones semánticas (SemVer) se omitirán. SemVer es un estándar aceptado para definir versiones de paquetes de software, con el formato `x.y.z`.\nDependabot supone que las versiones de este formulario siempre son `major.minor.patch`.\n\n* Usa `version-update:semver-patch` para incluir versiones de revisión.\n* Usa `version-update:semver-minor` para incluir versiones secundarias.\n* Usa `version-update:semver-major` para incluir versiones principales.\n\n##\n\n```\n `insecure-external-code-execution`\n \n \n \n```\n\nCompatible con: `bundler`, `mix` y `pip`.\n\nPermitir Dependabot ejecutar código externo en el manifiesto durante las actualizaciones. Para ver ejemplos, consulte [Permitir la ejecución de código externo](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot#allowing-external-code-execution).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Al conceder Dependabot acceso a uno o varios registros, la ejecución de código externo se deshabilita automáticamente para proteger el código de los paquetes en peligro.\n* Es posible que se produzca un error en las actualizaciones de versión sin la capacidad de ejecutar código.\n\nCuando se permite `insecure-external-code-execution`:\n\n* Dependabot ejecutará código en el manifiesto como parte del proceso de actualización de la versión.\n* El código solo tiene acceso a los administradores de paquetes de los registros asociados a ese valor de `updates`. No se permite el acceso a ninguno de los registros definidos en la configuración de `registries` de nivel superior.\n* Esto debería permitir que la actualización sea correcta pero también que un paquete que se haya puesto en riesgo robe las credenciales u obtenga acceso a los registros configurados.\n\nValor admitido: `allow`.\n\n##\n\n```\n `labels`\n \n \n \n```\n\nEspecifique sus propias etiquetas para todas las solicitudes de incorporación de cambios generadas para un administrador de paquetes. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Todas las solicitudes de incorporación de cambios tienen una etiqueta `dependencies`.\n* Si define más de un administrador de paquetes, se agrega una etiqueta adicional para el ecosistema o el lenguaje a cada solicitud de incorporación de cambios. Por ejemplo, `java` para actualizaciones de Gradle o `submodules` para actualizaciones de submódulo de Git.\n* Si las etiquetas de versión semántica (SemVer) están presentes en el repositorio, se aplicarán automáticamente para indicar el tipo de actualización de versión (`major`, `minor`o `patch`).\n* Dependabot crea estas etiquetas predeterminadas automáticamente, según sea necesario en el repositorio.\n\nCuando se define `labels`:\n\n* Se usan las etiquetas especificadas en lugar de las predeterminadas.\n* Las etiquetas semVer (si están presentes en el repositorio) se seguirán aplicando además de las etiquetas personalizadas definidas.\n* Si ninguna de estas etiquetas se define en el repositorio, entonces se ha ignorado.\n* Pude deshabilitar todas las etiquetas, incluidas las predeterminadas, con `labels: [ ]`.\n\nConfigurar esta opción también afectará a las solicitudes de incorporación de cambios para las actualizaciones de seguridad en los archivos de manifiesto de este administrador de paquetes, a menos que use `target-branch` para buscar actualizaciones de versión en una rama diferente a la predeterminada.\n\n##\n\n```\n `milestone`\n \n \n \n```\n\nAsocie todas las solicitudes de incorporación de cambios generadas para un administrador de paquetes con un hito. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* No se usan hitos.\n\nCuando se define `milestone`:\n\n* Todas las solicitudes de incorporación de cambios del administrador de paquetes se agregan al hito.\n\nValor admitido: identificador numérico de un hito.\n\n> \\[!TIP]\n> Si ve un hito, la parte final de la dirección URL de la página, después de `milestone`, es el identificador. Por ejemplo: `https://github.com///milestone/3`; consulta [Ver el avance de tu hito](/es/issues/using-labels-and-milestones-to-track-work/viewing-your-milestones-progress).\n\n##\n\n```\n `multi-ecosystem-groups`\n \n \n```\n\nDefina grupos que abarquen varios ecosistemas de paquetes para obtener una única Dependabot solicitud de incorporación de cambios que actualice todos los ecosistemas de paquetes admitidos. Este enfoque ayuda a reducir el número de Dependabot pull requests que recibes y agiliza tu flujo de trabajo de actualización de dependencias.\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Crea solicitudes de incorporación de cambios independientes para cada ecosistema de paquetes que tenga actualizaciones de dependencias.\n\nCuando se usa `multi-ecosystem-groups`:\n\n* Las actualizaciones en varios ecosistemas de paquetes del mismo grupo se combinan en una única solicitud de incorporación de cambios.\n* Los grupos tienen sus propias programaciones y pueden heredar o invalidar la configuración individual del ecosistema.\n\n### `multi-ecosystem-group`\n\nAsigna ecosistemas de paquetes individuales a un grupo de varios ecosistemas mediante el parámetro `multi-ecosystem-group` de la configuración `updates`.\n\n> \\[!IMPORTANT]\n> Las actualizaciones de varios ecosistemas requieren patrones de configuración específicos y tienen un comportamiento único de combinación de parámetros. Para obtener instrucciones de configuración completas, ejemplos de configuración y referencia detallada de parámetros, consulta [Configuración de actualizaciones de varios ecosistemas para Dependabot](/es/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates).\n\n```yaml copy\n# Basic `dependabot.yml` file defining a multi-ecosystem-group\nversion: 2\n\nmulti-ecosystem-groups:\n infrastructure:\n schedule:\n interval: \"weekly\"\n\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/\"\n patterns: [\"nginx\", \"redis\"]\n multi-ecosystem-group: \"infrastructure\"\n\n - package-ecosystem: \"terraform\"\n directory: \"/\"\n patterns: [\"aws\"]\n multi-ecosystem-group: \"infrastructure\"\n```\n\n##\n\n```\n `open-pull-requests-limit`\n \n \n```\n\nCambie el límite máximo de solicitudes de incorporación de cambios para las actualizaciones de versión abiertas en cualquier momento.\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Si se abren cinco solicitudes de incorporación de cambios con actualizaciones de versión, no se generan más solicitudes de incorporación de cambios hasta que algunas de las abiertas se combinen o se cierren.\n* Las actualizaciones de seguridad que tienen un límite separado e interno de diez solicitudes de incorporación de cambios abiertas que no se puede modificar.\n\nCuando se define `open-pull-requests-limit`:\n\n* Dependabot abre solicitudes de incorporación de cambios hasta el valor entero definido. Se puede establecer un valor grande para quitar de manera efectiva el límite de solicitudes de incorporación abiertas.\n* Puede deshabilitar temporalmente las actualizaciones de versiones de un administrador de paquetes estableciendo esta opción en cero; vea [Deshabilitar Dependabot version updates](/es/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#disabling-dependabot-version-updates).\n\n##\n\n```\n `package-ecosystem`\n \n \n```\n\n\n\n```\n **Opción obligatoria.** Defina un `package-ecosystem` elemento para cada administrador de paquetes que quiera Dependabot supervisar para las nuevas versiones. El repositorio también debe contener un archivo de bloqueo o de manifiesto de dependencias para cada administrador de paquetes, consulte [Ejemplo de archivo `dependabot.yml`](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#example-dependabotyml-file).\n```\n\n| Administrador de paquetes | El valor de YAML | Versiones compatibles |\n| ------------------------- | ---------------- | :-------------------: |\n| | | |\n| Bazel | `bazel` | v7, v8, v9 |\n| | | |\n| | | |\n| Bun | `bun` | >=v1.2.5 |\n| | | |\n| Bundler | `bundler` | |\n\n```\n v2 |\n```\n\n\\| Cargo | `cargo` | v1 |\n\\| Composer | `composer` | v2 |\n\\| |\n\\| Conda | `conda` | No aplicable |\n\\| |\n\\| Contenedores de desarrollo | `devcontainers` | No aplicable |\n\\| Docker | `docker` | v1 |\n\\| |\n\\| Docker Compose | `docker-compose` | v2, v3 |\n\\| |\n\\| |\n\\| SDK de .NET | `dotnet-sdk` | >=.NET Core 3.1 |\n\\| |\n\\| |\n\\| Gráficos de Helm | `helm` | v3 |\n\\| |\n\\| Hex | `mix` | v1 |\n\\| |\n\\| Julia | `julia` | >=v1.10 |\n\\| |\n\\| elm-package | `elm` | v0.19 |\n\\| submódulo de git | `gitsubmodule` | No aplicable |\n\\| GitHub Actions | `github-actions` | No aplicable |\n\\| Módulos de Go | `gomod` | v1 |\n\\| Gradle | `gradle` | No aplicable |\n\\| Maven | `maven` | No aplicable |\n\\| |\n\\| Flakes de Nix | `nix` | No aplicable |\n\\| |\n\\| npm | `npm` | v7, v8, v9, v10 |\n\\| NuGet | `nuget` |\n<=6.12.0 |\n\\| |\n\\| OpenTofu | `opentofu` | No aplicable |\n\\| |\n\\| pip | `pip` | 24.2 |\n\\| pip-compile | `pip` | 7.5.3 |\n\\| pipenv | `pip` | <= 2024.4.1 |\n\\| pnpm | `npm` | v7, v8, v9, v10 |\n\\| poetry | `pip` | v2 |\n\\| |\n\\| pre-commit | `pre-commit` | No aplicable |\n\\| |\n\\| pub | `pub` | v2 |\n\\| |\n\\| Cadena de herramientas de Rust | `rust-toolchain` | No aplicable |\n\\| |\n\\| Swift | `swift` | v5 |\n\\| Terraform | `terraform` | >= 0,13, <= 1.10.x |\n\\| |\n\\| uv | `uv` | v0 |\n\\| |\n\\| |\n\\| vcpkg | `vcpkg` | No aplicable |\n\\| |\n\\| Yarn | `npm` | v1, v2, v3, v4 |\n\n##\n\n```\n `pull-request-branch-name.separator`\n \n \n \n```\n\nEspecifique un separador que se usará al generar nombres de rama. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Generar nombres de rama con el formato: `dependabot/PACKAGE_MANAGER/DEPENDENCY`\n\nCuando se define `pull-request-branch-name.separator`:\n\n* Usa el carácter especificado en lugar de `/`.\n\nValores admitidos: `\"-\"`, `_`, `/`.\n\n> \\[!TIP]\n> Se debe aplicar escape al símbolo de guion para que no se interprete como el inicio de una lista de YAML vacía.\n\n##\n\n```\n `rebase-strategy`\n \n \n \n```\n\nDesactiva la rebase automática de pull requests generadas por Dependabot.\n\n```\n Dependabot El comportamiento por defecto es rebasear las pull requests abiertas cuando Dependabot detecta cualquier cambio en una versión o en una actualización de seguridad. \n Dependabot comprueba si hay cambios cuando:\n```\n\n* La programación se ejecuta para comprobar si hay actualizaciones de versión.\n* Reabres una solicitud pull cerrada Dependabot .\n* Puede cambiar el valor de `target-branch` en el archivo de configuración Dependabot, vea [`target-branch`](#target-branch-).\n* Una Dependabot pull request entra en conflicto tras un reciente envío a la rama objetivo.\n\nCuando `rebase-strategy` está configurado en `disabled`, Dependabot deja de rebasar las pull requests.\n\n> \\[!NOTE]\n> A las solicitudes de incorporación de cambios abiertas **antes** de deshabilitar la fusión mediante cambio de base se les sigue aplicando la fusión mediante cambio de base hasta 30 días después de que se hayan abierto. Esto afecta a todas las solicitudes de incorporación de cambios que tienen conflictos con la rama de destino y a todas las solicitudes de incorporación de cambios para las actualizaciones de versión.\n\n##\n\n```\n `registries`\n \n \n \n```\n\nConfigure el acceso a los registros de paquetes privados para permitir Dependabot actualizar una gama más amplia de dependencias, consulte [Configuración del acceso a registros privados para Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot) y [Guía para la configuración de registros privados para Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/guidance-for-the-configuration-of-private-registries-for-dependabot).\n\nHay 2 ubicaciones en el archivo `dependabot.yml` donde puede usar la clave `registries`:\n\n1. En el nivel superior, donde define los registros privados que quiere usar y su información de acceso, consulte [Configuración del acceso a registros privados para Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot).\n2. Dentro de los bloques de `updates`, donde puede especificar qué registros privados debe usar cada administrador de paquetes.\n\n ```\n Dependabot el comportamiento predeterminado es generar solicitudes de incorporación de cambios solo para actualizar las dependencias almacenadas en registros accesibles públicamente.\n ```\n\nCuando el Dependabot archivo de configuración tiene una sección de nivel `registries` superior, definiendo el acceso a uno o varios registros privados, puede configurar cada uno `package-ecosystem` para usar uno o varios de estos registros privados.\n\nCuando se define `registries` para un administrador de paquetes:\n\n* Se comprueba cada registro privado especificado para un administrador de paquetes en busca de actualizaciones de versión y seguridad.\n* Dependabot usa los detalles de acceso definidos en la sección de nivel `registries` superior.\n\nValores admitidos: `REGISTRY_NAME` o `\"*\"`\n\n##\n\n```\n `schedule`\n \n \n\n **Opción obligatoria.** Defina la frecuencia para comprobar si hay versiones nuevas para cada administrador de paquetes que configure con el parámetro `interval`. Opcionalmente, para intervalos diarios y semanales, puedes personalizar cuándo Dependabot comprueba las actualizaciones. Para ejemplos, consulta [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates).\n```\n\n| Parámetros | Propósito |\n| ----------------------- | --------- |\n| [`interval`](#interval) | |\n\n```\n **Obligatorio.** Define la frecuencia de Dependabot. |\n```\n\n\\| [`day`](#day) | Especificar el día que se ejecutará para un intervalo **semanal**. |\n\\| [`time`](#time) | Especifica la hora de ejecución. |\n\\| |\n\\| [`cronjob`](#cronjob) | Define la expresión Cron si el tipo de intervalo es `cron`. |\n\\| |\n\\| [`timezone`](#timezone) | Especifica la zona horaria del valor `time`. |\n\n### `interval`\n\nValores admitidos: `daily`, `weekly`, `monthly`, `quarterly`, `semiannually`, `yearly` o `cron`\n\nCada administrador de paquetes **debe** definir un intervalo de programación.\n\n* use `daily` para ejecutarse cada día de la semana, de lunes a viernes.\n* Use `weekly` para ejecutarse una vez a la semana, de manera predeterminada el lunes.\n* Usa `monthly` para realizar la ejecución el primer día de cada mes.\n* Usa `quarterly` para ejecutarse el primer día de cada trimestre (enero, abril, julio y octubre).\n* Usa `semiannually` para ejecutarse cada seis meses, el primer día de enero y julio.\n* Usa `yearly` para ejecutarse el primer día de enero.\n* Usa `cron` para la opción de programación basada en expresiones Cron. Consulte [`cronjob`](#cronjob).\n\n> \\[!NOTE]\n> Los valores admitidos `quarterly`, `semiannually`y `yearly` solo están disponibles en GitHub Enterprise Server la versión 3.19.\n\nDe forma predeterminada, Dependabot asigna aleatoriamente una hora para aplicar todas las actualizaciones del archivo de configuración. Puedes usar los parámetros `time` y `timezone` para establecer un tiempo de ejecución específico para todos los intervalos.\\\nSi usa un `cron` intervalo, puede definir la hora de actualización con una `cronjob` expresión.\n\n### `day`\n\nValores admitidos: `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday` o `sunday`\n\nOpcionalmente, ejecute actualizaciones **semanales** para un administrador de paquetes en un día específico de la semana.\n\n### `time`\n\nFormato: `hh:mm`\n\nOpcionalmente, ejecute todas las actualizaciones de un administrador de paquetes a una hora específica del día. De manera predeterminada, las horas se interpretan como UTC.\n\n### `cronjob`\n\nValores admitidos: expresión Cron válida en sintaxis de cron o expresión natural.\n\nLa sintaxis de cron tiene cinco campos separados por un espacio, y cada campo representa una unidad de tiempo.\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\nEjemplos: `0 9 * * *`, `every day at 5pm`\n\n```\n `0 9 * * *` es equivalente a \"todos los días a las 9:00\". \n `every day at 5pm` equivale a `0 17 * * *`.\n```\n\n> \\[!NOTE]\n>\n> * Las zonas horarias deben especificarse en el [`timezone`](#timezone) parámetro y no en .`cronjob`\n> * Se requiere una programación de tipo `cronjob` para usar un intervalo `cron`.\n\n```yaml copy\n\n# Basic `dependabot.yml` file for cronjob\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates based on `cronjob` value\n schedule:\n interval: \"cron\"\n cronjob: \"0 9 * * *\"\n```\n\n### `timezone`\n\nEspecifica una zona horaria para el valor `time`. La zona horaria predeterminada es `UTC`.\n\nEl identificador de zona horaria debe coincidir con una zona horaria de la base de datos mantenida por [iana](https://www.iana.org/time-zones); consulte [Lista de zonas horarias de base de datos de tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n\n##\n\n```\n `target-branch`\n \n \n```\n\nDefina una rama específica para comprobar si hay actualizaciones de versión y para dirigir las solicitudes de incorporación de cambios para las actualizaciones de versión. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Dependabot usa la rama predeterminada para el repositorio, consulte [Acerca de la rama predeterminada](/es/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#about-the-default-branch).\n\nCuando se define `target-branch`:\n\n* Solo se comprueban si hay actualizaciones de versión en los archivos de manifiesto de la rama de destino.\n* Todas las solicitudes de cambios para las actualizaciones de versión se abren con la rama especificada como destino.\n* Las opciones definidas para `package-ecosystem` ya no se aplican a las actualizaciones de seguridad porque las actualizaciones de seguridad siempre usan la rama predeterminada para el repositorio.\n\n##\n\n```\n `exclude-paths`\n \n \n```\n\nÚsase para especificar rutas de directorios y archivos que Dependabot deben ignorar al escanear manifiestos y dependencias. Esta opción es útil cuando quieres evitar actualizaciones de dependencias en determinadas ubicaciones, como recursos de prueba, código de proveedores o archivos específicos.\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Todos los directorios y archivos de la instancia de `directory` especificada se incluyen en el examen de actualizaciones, a menos que esta opción los excluya.\n\nCuando se define `exclude-paths`:\n\n* Todos los archivos y directorios que coinciden con las rutas de acceso especificadas se omiten durante los exámenes de actualización de la entrada `package-ecosystem` especificada.\n\n| Parámetro | Propósito |\n| --------------- | --------------------------------------------------------------------------- |\n| `exclude-paths` | Lista de patrones globales para archivos o directorios que se van a omitir. |\n\nSe admiten patrones globales, como `**` para la coincidencia recursiva y `*` para caracteres comodín de segmento único. Los patrones son relativos al valor `directory` especificado para la configuración de actualización. Cada ecosistema puede tener su propia configuración de `exclude-paths`.\n\n### Example\n\n```yaml copy\nversion: 2\nupdates:\n - package-ecosystem: \"npm\"\n directory: \"/\"\n schedule:\n interval: \"daily\"\n exclude-paths:\n - \"src/test/assets\"\n - \"vendor/**\"\n - \"src/*.js\"\n - \"src/test/helper.js\"\n\n# Sample patterns that can be used-\n\n# Pattern: docs/*.json\n# Matches: docs/foo.json, docs/bar.json\n\n# Pattern: *.lock\n# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)\n\n# Pattern: test/**\n# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt\n\n# Pattern: config/settings.yml\n# Matches: config/settings.yml\n\n# Pattern: **/*.md\n# Matches: README.md, docs/guide.md, any/depth/file.md\n\n# Pattern: src/*\n# Matches: src/main.rb, src/app.js\n# Does NOT match: src/utils/helper.rb\n\n# Pattern: hidden/.*\n# Matches: hidden/.env, hidden/.secret\n```\n\nEn este ejemplo, Dependabot omitirá el `src/test/assets` directorio, todos los archivos de `vendor/`, todos los archivos de JavaScript directamente en `src/`y el archivo `src/test/helper.js` específico al buscar actualizaciones.\n\n##\n\n```\n `vendor`\n \n \n \n```\n\nCompatible con: solo `bundler` y `gomod`.\n\nDile Dependabot que mantengas tus dependencias de proveedores así como las dependencias definidas por los archivos manifiestos. Una dependencia se describe como \"delegada a proveedores\" o \"en caché\" al almacenar el código en el repositorio; consulte la documentación de [`bundle cache`](https://bundler.io/man/bundle-cache.1.html) y la documentación de [`go mod vendor`](https://golang.org/ref/mod#go-mod-vendor).\n\nPara ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#updating-vendored-dependencies).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Mantener solo las dependencias registradas en los archivos de manifiesto y bloqueo identificados para Bundler.\n* Generar solicitudes de incorporación de cambios de actualización de seguridad y versión que actualicen los números de versión registrados en los archivos de manifiesto y bloqueo.\n* Para módulos de Go, las dependencias delegadas a proveedores se identifican y mantienen automáticamente como si `vendor` estuviera habilitado.\n\nCuando `vendor` está habilitado:\n\n* Dependabot también mantiene las dependencias de Bundler que se almacenan en el `_vendor/cache_` directorio del repositorio.\n* Las solicitudes de incorporación de cambios a veces contendrán actualizaciones de una dependencia almacenada en el repositorio.\n\nValores admitidos: `true` o `false`\n\n##\n\n```\n `versioning-strategy`\n \n \n \n```\n\nCompatible con: `bundler`, `cargo`, `composer`, `mix`, `npm`, `pip`, `pub`, y `uv`\n\nDefina cómo Dependabot debe editar los archivos de manifiesto. Para ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#defining-a-versioning-strategy).\n\n```\n Dependabot comportamiento predeterminado:\n```\n\n* Intente diferenciar entre dependencias de aplicación y biblioteca.\n* Para las aplicaciones, aumente siempre el requisito de versión mínima para que coincida con la versión nueva. La estrategia `increase`.\n* Para las bibliotecas, amplíe los requisitos de versión permitida para que incluyan tanto la versión nueva como la anterior, siempre que sea posible. La estrategia `widen`.\n\nCuando `versioning-strategy` se define, Dependabot usa la estrategia especificada.\n\n| Importancia | Comportamiento |\n| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `auto` | Comportamiento predeterminado. |\n| `increase` | Aumentar siempre el requisito de versión mínima para que coincida con la versión nueva. Si ya existe un rango, por lo general solo se aumenta el límite inferior. |\n| `increase-if-necessary` | Deja el requisito de versión sin cambios si ya permite la nueva versión (Dependabot sigue actualizando la versión resuelta). De lo contrario, amplía el requisito. |\n| `lockfile-only` | Crear únicamente solicitudes de cambios para actualizar archivos de bloqueo. Ignorar cualquier versión nueva que pudiera requerir cambios en el paquete del manifiesto. |\n| `widen` | Ampliar los requisitos de versión permitida para que incluyan tanto la versión nueva como la anterior, siempre que sea posible. Por lo general, esto solo aumenta el requisito de versión máxima permitida. |\n\nPor ejemplo, si la versión actual es `1.0.0` y la restricción actual es `^1.0.0` las distintas estrategias generarían las siguientes actualizaciones:\n\nVersión nueva `1.2.0`\n\n* `increase`: restricción nueva `^1.2.0`\n* `increase-if-necessary`: restricción nueva `^1.0.0`\n* `widen`: restricción nueva `^1.0.0`\n\nVersión nueva `2.0.0`\n\n* `increase`: restricción nueva `^2.0.0`\n* `increase-if-necessary`: restricción nueva `^2.0.0`\n* `widen`: restricción nueva `>=1.0.0 <3.0.0`\n\n> \\[!NOTE]\n> Si el administrador de paquetes que usa aún no admite la configuración del parámetro `versioning-strategy` o no admite un valor que necesite, el código de estrategia es código abierto, por lo que si desea que un ecosistema determinado admita una nueva estrategia, siempre le damos la bienvenida a enviar una solicitud de incorporación de cambios en .\n\n### Etiquetas de control de versiones\n\n\n\n* Representan las fases del ciclo de vida de la versión de software, como las versiones alfa, beta y estable.\n* Permiten que los publicadores distribuyan sus paquetes de forma más eficaz.\n* Indican la estabilidad de una versión y comunican lo que los usuarios deben esperar en términos de características y estabilidad.\n\nDependabot reconoce una variedad de etiquetas de control de versiones para versiones preliminares, versiones estables y etiquetas personalizadas en los distintos ecosistemas.\n\nEl archivo `dependabot.yml` no controla las etiquetas de control de versiones que puedes usar, pero puedes definir en opciones de configuración como, por ejemplo, [`ignore`](/es/code-security/dependabot/working-with-dependabot/dependabot-options-reference#ignore--) las etiquetas de control de versiones admitidas para las que deseas omitir las actualizaciones.\n\n#### Etiquetas de control de versiones admitidas\n\n\\| **Administrador de paquetes** |\n**Valor de YAML** |\n**Etiquetas admitidas** |\n**Ejemplos** |\n\\|---------------------|----------------|--------------------|--------------|\n\\| Maven | `maven` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`spring-security-web@5.6.0-SNAPSHOT`, `spring-core@5.2.0.RELEASE` |\n\\| npm | `npm` |\n`alpha`, `beta`, `canary`, `dev`, `experimental`, `latest`, `legacy`, `next`, `nightly`, `rc`, `release`, `stable` |\n`lodash@beta`, , `react@latest`, `express@next` |\n\\| pnpm | `npm` |\n`alpha`, `beta`, `canary`, `dev`, `experimental`, `latest`, `legacy`, `next`, `nightly`, `rc`, `release`, `stable` |\n`lodash@1.2.0-alpha`, , `react@alpha`, `vue@next` |\n\\| Yarn | `npm` |\n`alpha`, `beta`, `canary`, `dev`, `experimental`, `latest`, `legacy`, `next`, `nightly`, `rc`, `release`, `stable` |\n`lodash@1.2.0-alpha`, , `axios@latest`, `moment@nightly` |\n\n#### Glosario de etiquetas de control de versiones\n\n***\n\n```\n `alpha`:** la versión temprana, puede ser inestable y tener características incompletas.\n```\n\n***\n\n```\n `beta`:** más estable que alfa, pero todavía puede tener errores.\n```\n\n***\n\n```\n `canary`:** se actualiza periódicamente la versión preliminar para las pruebas.\n```\n\n***\n\n```\n `dev`:** representa las versiones de desarrollo.\n```\n\n***\n\n```\n `experimental`:** versiones con características experimentales.\n```\n\n***\n\n```\n `latest`:** la versión estable más reciente.\n```\n\n***\n\n```\n `legacy`:** versiones anteriores o en desuso.\n```\n\n***\n\n```\n `next`:** la próxima versión de lanzamiento.\n```\n\n***\n\n```\n `nightly`:** versiones compiladas por la noche; a menudo incluye los cambios más recientes.\n```\n\n***\n\n```\n `rc`:** versión candidata para lanzamiento, cerca de la versión estable.\n```\n\n***\n\n```\n `release`:** la versión de lanzamiento oficial.\n```\n\n***\n\n```\n `stable`:** la versión más fiable y lista para producción.\n```\n\n\n\n## Clave `registries` de nivel superior\n\nEspecifique los detalles de autenticación que Dependabot pueden usar para acceder a los registros de paquetes privados, incluidos los registros hospedados por GitLab o Bitbucket.\n\nEl valor de la clave `registries` es una matriz asociativa, de la cual cada elemento consiste en una clave que identifica un registro en particular y un valor que es una matriz asociativa que especifica la configuración que se requiere para acceder a dicho registro. El siguiente archivo `dependabot.yml` configura un registro identificado como `dockerhub` en la sección `registries` del archivo y, después, hace referencia a este en la sección `updates` del archivo.\n\n```yaml copy\n# Minimal settings to update dependencies stored in one private registry\n\nversion: 2\nregistries:\n dockerhub: # Define access for a private registry\n type: docker-registry\n url: registry.hub.docker.com\n username: octocat\n password: ${{secrets.DOCKERHUB_PASSWORD}}\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/docker-registry/dockerhub\"\n registries:\n - dockerhub # Allow version updates for dependencies in this registry\n schedule:\n interval: \"monthly\"\n```\n\nUtilizarás las siguientes opciones para especificar la configuración de acceso. La configuración del registro debe contener un elemento `type` y otro `url`, y normalmente incluirán una combinación `username` y `password`, o un elemento `token`.\n\n| Parámetros | Fin |\n| :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `REGISTRY_NAME` | **Obligatorio:** define un identificador para el registro. |\n| `type` | **Obligatorio:** identifica el tipo de registro. |\n| Detalles de la autenticación | **Obligatorio:** los parámetros admitidos para proporcionar detalles de autenticación varían para los registros de diferentes tipos. |\n| `url` | **Obligatorio:** la URL que se usa para acceder a las dependencias en este registro. El protocolo es opcional. Si no se especifica, se da por hecho el valor `https://`. El Dependabot agrega o ignora las diagonales iniciales conforme sea necesario. |\n| `replaces-base` | Si el valor booleano es `true`, Dependabot resuelve las dependencias mediante el valor `url` especificado en lugar de la URL base de ese ecosistema. |\n\nPara obtener información detallada sobre las opciones disponibles, así como recomendaciones y consejos al configurar registros privados, consulta [Guía para la configuración de registros privados para Dependabot](/es/code-security/dependabot/working-with-dependabot/guidance-for-the-configuration-of-private-registries-for-dependabot).\n\n###\n\n```\n `type` y detalles de autenticación\n```\n\nLos parámetros usados para proporcionar detalles de autenticación para el acceso a un registro privado varían según el registro `type`.\n\n| Registro `type` | Parámetros de autenticación obligatorios |\n| --------------------- | ---------------------------------------- |\n| `cargo-registry` | `token` |\n| `composer-repository` | |\n\n```\n `username` y `password`
o OIDC con `tenant-id` y `client-id` |\n```\n\n\\| `docker-registry` |\n`username` y `password`
o OIDC con `tenant-id` y `client-id` |\n\\| `git` |\n`username` y `password`
o OIDC con `tenant-id` y `client-id` |\n\\| `hex-organization` |\n`organization` y `key` |\n\\| `hex-repository` |\n`repo` y `auth-key` opcionalmente con el valor `public-key-fingerprint`correspondiente |\n\\| `maven-repository` |\n`username` y `password`
o OIDC con `tenant-id` y `client-id` |\n\\| `npm-registry` |\n`username` y `password`
o bien `token`
o OIDC con `tenant-id` y `client-id` |\n\\| `nuget-feed` |\n`username` y `password`
o bien `token`
o OIDC con `tenant-id` y `client-id` |\n\\| `pub-registry` | `token` |\n\\| `python-index` |\n`username` y `password`
o bien `token`
o OIDC con `tenant-id` y `client-id` |\n\\| `rubygems-server` |\n`username` y `password`
o bien `token`
o OIDC con `tenant-id` y `client-id` |\n\\| `terraform-registry` | `token` |\n\nTodos los datos confidenciales usados para la autenticación se deben almacenar de forma segura y hacerles referencia desde esa ubicación segura; consulte [Configuración del acceso a registros privados para Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot).\n\n> \\[!TIP]\n> Si la cuenta es una cuenta de GitHub, puede usar un GitHub personal access token en lugar de la contraseña.\n\nPara obtener más información sobre la compatibilidad con OIDC para Dependabot, vea [OpenID Connect](/es/actions/concepts/security/openid-connect#oidc-support-for-dependabot) y [Configuración del acceso a registros privados para Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot#using-oidc-for-authentication).\n\n###\n\n```\n `url` y `replaces-base`\n```\n\nEl parámetro `url` define dónde acceder a un registro. Cuando el parámetro opcional `replaces-base` está habilitado (`true`), Dependabot resuelve las dependencias utilizando el valor de `url` en lugar de la dirección URL base de ese ecosistema específico."}