{"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| Dependabot sintaxis de configuración a utilizar. Siempre: `2` | | |\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## `allow`\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated).\n\nDependabot comportamiento predeterminado:\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### `dependency-name` (`allow`)\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### `dependency-type` (`allow`)\n\n| Tipos de dependencia | Administradores de paquete compatibles | Permitir actualizaciones |\n| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `direct` | Todos | Todas las dependencias definidas explícitamente. |\n| `indirect` | | |\n| `bundler`, `pip`, `composer`, `cargo`, , `gomod`, `uv` | Dependencias de dependencias directas (también conocidas como dependencias secundarias o dependencias transitivas). | |\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### `update-types` (`allow`)\n\n`update-types` solo afecta a las actualizaciones de *versión* , no a *las actualizaciones de seguridad*.\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## `assignees`\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/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\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## `commit-message`\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/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\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## `cooldown`\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/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#setting-up-a-cooldown-period-for-dependency-updates).\n\nDependabot comportamiento predeterminado:\n\n* Compruebe si hay actualizaciones según la programación definida a través de `schedule.interval`.\n* Aplique un **período de espera predeterminado de 3 días** a las actualizaciones de versión, aunque `cooldown` no esté configurado. Una nueva versión no se considera para una actualización de versión hasta 3 días después de su lanzamiento.\n **Este enfriamiento predeterminado no se aplica a las actualizaciones de seguridad.**\n\nPuede configurar la `cooldown` opción para personalizar estos períodos de enfriamiento predeterminados y controlar las dependencias a las que se aplican. Cuando se define **`cooldown`**:\n\n1. Dependabot comprueba si hay actualizaciones según la configuración definida `schedule.interval` .\n2. Dependabot comprueba si hay alguna configuración de enfriamiento.\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### **Configuración de `cooldown`**\n\nPuedes especificar la duración de la recuperación mediante las opciones siguientes.\n\n| Parámetro | Description |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `default-days` | |\n| **Período de enfriamiento predeterminado para las dependencias** sin reglas específicas (opcional). Si no se especifica, Dependabot aplica un enfriamiento predeterminado de 3 días. | |\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 que admiten `cooldown`. La `default-days` opción es compatible con todos los administradores de paquetes enumerados, mientras que `semver-major-days`, `semver-minor-days`y `semver-patch-days` solo se admiten cuando se indica.\n\n| Administrador de paquetes | Días predeterminados compatibles | Días SemVer-bump admitidos |\n| ------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |\n| | | |\n| Bazel | | |\n| | | |\n| Bundler | | |\n| Bun | | |\n| Cargo | | |\n| Composer | | |\n| | | |\n| Conda | | |\n| | | |\n| | | |\n| Deno | | |\n| | | |\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 (Hex) | | |\n| | | |\n| Julia | | |\n| | | |\n| Maven | | |\n| | | |\n| Flakes de Nix | | |\n| | | |\n| NPM y Yarn | | |\n| NuGet | | |\n| | | |\n| OpenTofu | | |\n| | | |\n| Pip | | |\n| | | |\n| pre-commit | | |\n| | | |\n| Pub | | |\n| | | |\n| Cadena de herramientas de Rust | | |\n| | | |\n| | | |\n| sbt | | |\n| | | |\n| Swift | | |\n| Terraform | | |\n| UV | | |\n| | | |\n| vcpkg | | |\n| | | |\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## `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](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-multiple-locations-for-manifest-files).\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## `enable-beta-ecosystems`\n\nNo se usa actualmente.\n\n## `groups`\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/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates).\n\nDependabot comportamiento predeterminado:\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### `dependency-type` (`groups`)\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### `group-by` (`groups`)\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**Limitaciones de la agrupación entre directorios**\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### `patterns` y `exclude-patterns` (`groups`)\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### `update-types` (`groups`)\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore).\n\n## `ignore`\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-dependencies).\n\nDependabot comportamiento predeterminado:\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### `dependency-name` (`ignore`)\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### `versions` (`ignore`)\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: use `[1.4,)`\n\nPara ejemplos, consulta [Control de qué dependencias actualiza Dependabot](/es/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-versions-or-ranges-of-versions).\n\n### `update-types` (`ignore`)\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## `insecure-external-code-execution`\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/configure-access-to-private-registries#allowing-external-code-execution).\n\nDependabot comportamiento predeterminado:\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## `labels`\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/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\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## `milestone`\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/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\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## `multi-ecosystem-groups`\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\nDependabot comportamiento predeterminado:\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/how-tos/secure-your-supply-chain/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## `open-pull-requests-limit`\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\nDependabot comportamiento predeterminado:\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\n> \\[!NOTE]\n> *Las solicitudes de extracción* de actualización de seguridad no están sujetas a este límite y no contabilizan para este. No hay límite en el número de solicitudes de extracción abiertas para las actualizaciones de seguridad.\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/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#disabling-dependabot-version-updates).\n\n## `package-ecosystem`\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`](/es/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#example-dependabotyml-file).\n\n| Administrador de paquetes | El valor de YAML | Versiones compatibles |\n| ------------------------------ | ---------------- | :-------------------: |\n| | | |\n| Bazel | `bazel` | v7, v8, v9 |\n| | | |\n| Bun | `bun` | >=v1.1.39 |\n| Bundler | `bundler` | v2 |\n| Cargo | `cargo` | v1 |\n| Composer | `composer` | v2 |\n| | | |\n| Conda | `conda` | No aplicable |\n| | | |\n| | | |\n| Deno | `deno` | >=v2 |\n| | | |\n| Contenedores de desarrollo | `devcontainers` | No aplicable |\n| Docker | `docker` | v1 |\n| Docker Compose | `docker-compose` | v2, v3 |\n| SDK de .NET | `dotnet-sdk` | >=.NET Core 3.1 |\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, v11 |\n| NuGet | `nuget` | <=6.12.0 |\n| | | |\n| OpenTofu | `opentofu` | No aplicable |\n| | | |\n| pip | `pip` | 26.1.1 |\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| | | |\n| sbt | `sbt` | No aplicable |\n| | | |\n| Swift | `swift` | v5, v6 |\n| Terraform | `terraform` | >= 0,13, <= 1,15.x |\n| uv | `uv` | v0.11 |\n| | | |\n| vcpkg | `vcpkg` | No aplicable |\n| | | |\n| Yarn | `npm` | v1, v2, v3, v4 |\n\n## `pull-request-branch-name`\n\nConfigure la forma en que Dependabot genera nombres de ramas para las solicitudes de incorporación de cambios. Puede personalizar el separador, el prefijo, la longitud, el uso de mayúsculas y minúsculas, el separador de palabras y proporcionar una plantilla personalizada. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\n\n* Generar nombres de rama con el formato: `dependabot/PACKAGE-MANAGER/DEPENDENCY`\n\n| Parámetro | Tipo | Predeterminado | Description |\n| --------------------------------------- | --------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------- |\n| [`separator`](#separator) | String | `\"/\"` | Carácter usado entre segmentos del nombre de la rama. |\n| [`prefix`](#prefix) | Cadena (máximo de 50 caracteres) | `\"dependabot\"` | Cadena antepuesta al nombre de la rama. |\n| [`max-length`](#max-length) | Entero (20–244) | `100` | Longitud máxima del nombre de la rama en caracteres. |\n| [`word-separator`](#word-separator) | String | No establecido | Carácter para reemplazar caracteres de subrayado (`_`) en el contenido del nombre de rama después del prefijo. |\n| [`branch-name-case`](#branch-name-case) | String | No establecido | Aplique la conversión entre mayúsculas y minúsculas al contenido del nombre de la rama después del prefijo. |\n| [`template`](#template) | Cadena (máximo de 200 caracteres) | No establecido | Plantilla de formato personalizado con marcadores de posición. |\n\nTodas las opciones son combinables. Cuando `template` se establece junto con opciones simples, el orden de procesamiento es:\n\n1. Representación de plantillas (sustitución de marcadores de posición)\n2. Reemplazo del separador (`/` reemplazado por separador configurado)\n3. Reemplazo del separador de palabras (`_` reemplazado por el separador de palabras configurado)\n4. Conversión entre mayúsculas y minúsculas aplicada al contenido después del prefijo\n5. Truncamiento por longitud máxima\n\n### `separator`\n\nEspecifique un carácter para usar en lugar de `/` entre los segmentos del nombre de la rama.\n\nValores admitidos: `\"-\"`, `_`, `/`.\n\nPor ejemplo, con `separator: \"-\"`: `dependabot/npm_and_yarn/lodash-4.17.21` se convierte en `dependabot-npm_and_yarn-lodash-4.17.21`.\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### `prefix`\n\nEspecifique una cadena personalizada que se usará al principio del nombre de la rama en lugar del valor predeterminado `dependabot`.\n\nEl valor puede tener hasta 50 caracteres.\n\nPor ejemplo, con `prefix: \"deps\"`: `dependabot/npm_and_yarn/lodash-4.17.21` se convierte en `deps/npm_and_yarn/lodash-4.17.21`.\n\n### `max-length`\n\nEstablezca la longitud máxima permitida para los nombres de rama generados.\n\n* Valor mínimo: `20`.\n* Valor máximo: `244`.\n* Valor predeterminado: `100`.\n* Cuando un nombre de rama supera este límite, se trunca y se anexa un sufijo hash para conservar la unicidad.\n\nPor ejemplo, con `max-length: 40`, un nombre de rama como `dependabot/npm_and_yarn/some-long-dependency-name-1.0.0` se trunca a 40 caracteres con un sufijo hash.\n\n### `word-separator`\n\nEspecifique un carácter para reemplazar los caracteres de subrayado (`_`) en todo el contenido del nombre de rama después del prefijo, incluidos los nombres del administrador de paquetes, los nombres de dependencia, los nombres de grupo y las rutas de acceso de directorio.\n\nPor ejemplo, con `word-separator: \"-\"`:\n\n* `npm_and_yarn` → `npm-and-yarn`\n* `front_end_dir` → `front-end-dir`\n\n### `branch-name-case`\n\nAplique la conversión entre mayúsculas y minúsculas al contenido del nombre de la rama después del prefijo.\n\nValores admitidos: `\"lowercase\"`, `\"uppercase\"`\n\nPor ejemplo, con `branch-name-case: \"lowercase\"`: `dependabot/npm_and_yarn/Lodash-4.17.21` se convierte en `dependabot/npm_and_yarn/lodash-4.17.21`.\n\n### `template`\n\nDefina un formato de nombre de rama personalizado mediante marcadores de posición. La plantilla proporciona control total sobre la estructura de los nombres de rama generados. Para ejemplos, consulta [Personalización de las pull requests de Dependabot para adaptarlas a tus procesos](/es/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nLos marcadores de posición disponibles dependen de la estrategia de actualización:\n\n| Marcador de posición | Solo actualizaciones | Actualizaciones agrupadas | Grupos de varios ecosistemas | Description |\n| -------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------- |\n| `{prefix}` | | | | Prefijo configurado (valor predeterminado `dependabot`). |\n| `{package_manager}` | | | | Identificador del ecosistema de paquetes (por ejemplo, `npm_and_yarn`). |\n| `{directory}` | | | | Directorio de archivos de dependencia. |\n| `{target_branch}` | | | | La rama de destino si está configurada. |\n| `{dependency}` | | | | El nombre o los nombres de la dependencia. |\n| `{version}` | | | | Nueva versión o referencia. |\n| `{group_name}` | | | | Nombre del grupo configurado. |\n| `{name}` | | | | Nombre adecuado para la estrategia: dependencia y versión para actualizaciones individuales, nombre de grupo para actualizaciones agrupadas. |\n\nReglas de validación de plantillas:\n\n* Todos los marcadores de posición deben estar reconocidos y permitidos por la estrategia de actualización utilizada.\n* Las llaves deben estar bien formadas (sin cerrar `{` ni `}`).\n* El uso `{package_manager}` de en una plantilla de grupo de varios ecosistemas genera un error de validación porque no se aplica ningún administrador de paquetes único.\n* El nombre de la rama representada debe ser un nombre de referencia de Git válido. No se permiten caracteres como espacios, `~`, `^`, `:`, `?``*`, `[`, y `\\` , y secuencias como `..` o `@{` se rechazan.\n* En el caso de las actualizaciones agrupadas y de varios ecosistemas, se anexa automáticamente un resumen de 10 caracteres al nombre de la rama para garantizar la unicidad. Esto no está controlado por el usuario.\n\n## `rebase-strategy`\n\nDesactiva la rebase automática de pull requests generadas por Dependabot.\n\nDependabot 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.\nDependabot comprueba si hay cambios cuando:\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## `registries`\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/configure-access-to-private-registries) 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/configure-private-registries).\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/configure-access-to-private-registries).\n2. Dentro de los bloques de `updates`, donde puede especificar qué registros privados debe usar cada administrador de paquetes.\n\nDependabot el comportamiento predeterminado es generar solicitudes de incorporación de cambios solo para actualizar las dependencias almacenadas en registros accesibles públicamente.\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## `schedule`\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 [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).\n\n| Parámetros | Propósito |\n| ---------------------------------------------------- | ------------------------------------------------------------------ |\n| [`interval`](#interval) | |\n| **Obligatorio.** Define la frecuencia de Dependabot. | |\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`0 9 * * *` es equivalente a \"todos los días a las 9:00\".\n`every day at 5pm` equivale a `0 17 * * *`.\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## `target-branch`\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/tutorials/secure-your-dependencies/customizing-dependabot-prs).\n\nDependabot comportamiento predeterminado:\n\n* Dependabot usa la rama predeterminada para el repositorio, consulte [Acerca de la rama predeterminada](/es/pull-requests/reference/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## `exclude-paths`\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\nDependabot comportamiento predeterminado:\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## `vendor`\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#updating-vendored-dependencies).\n\nDependabot comportamiento predeterminado:\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## `versioning-strategy`\n\nCompatible con: `bundler`, `cargo`, `composer`, `helm`, `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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-a-versioning-strategy).\n\nDependabot comportamiento predeterminado:\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 diferentes 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/reference/supply-chain-security/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\\| |\n\\| sbt | `sbt` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`akka-actor@2.7.0-RC1`, `play-json@3.0.0-M1` |\n\\| |\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\\| Gestor de paquetes | `bundler` | Cualquier identificador de versión preliminar (normalmente `alpha`, `beta`, `rc`, `pre`) |\n`rails@1.0.0.alpha`, , `rack@1.0.0.beta1`, `rspec@1.0.0.rc2` |\n\\| Cargo | `cargo` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`, `dev`) |\n`serde@1.0.0-alpha`, `tokio@0.2.0-preview.3`, , `clap@4.0.0-rc.1`, `rand@1.0.0-dev` |\n\\| pip | `pip` |\n`a`, `b`, `rc`, , `dev`, `post` |\n`requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, , `black@1.0.0.dev5`, `pandas@2.0.5.post1` |\n\\| pipenv | `pip` |\n`a`, `b`, `rc`, , `dev`, `post` |\n`requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, , `black@1.0.0.dev5`, `pandas@2.0.5.post1` |\n\\| pip-compile | `pip` |\n`a`, `b`, `rc`, , `dev`, `post` |\n`requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, , `black@1.0.0.dev5`, `pandas@2.0.5.post1` |\n\\| poesía | `pip` |\n`a`, `b`, `rc`, , `dev`, `post` |\n`requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, , `black@1.0.0.dev5`, `pandas@2.0.5.post1` |\n\\| Gradle | `gradle` |\n`alpha`, `a`, `beta`, `b`, `milestone`, `m`, `rc`, `cr`, `snapshot`, `ga`, `final`, `release`, `sp` (no distingue mayúsculas de minúsculas) |\n`spring-boot-starter@3.0.0-RC1`, `kotlin-stdlib@2.0.0-beta`, `guava@33.0.0-SNAPSHOT`, , `junit@5.10.0-M2`, `ktor@2.3.0-rc.1` |\n\\| Elm | `elm` | Ninguno: solo `MAJOR.MINOR.PATCH` estricto (sin versiones preliminares) |\n`elm/core@1.0.0`, , `elm/html@2.3.1`, `elm/json@10.0.0` |\n\\| Docker | `docker` |\n`alpha`, `beta`, `rc`, `dev`, `preview`, `pre``nightly`, , `snapshot`, `canary``unstable` (detección heurística) |\n`nginx@1.25.0-rc1`, `node@20.0.0-alpha.1`, `redis@7.0.0-nightly`, , `alpine@3.18.0-dev`, `ubuntu@22.04-preview` |\n\\| submódulo de git | `gitsubmodule` | Ninguno: pines para confirmar SHA o etiquetas de git (sin esquema de control de versiones) |\n`my-lib@abc1234`, `shared-utils@v1.2.0` |\n\\| Módulos de Go | `gomod` |\n`alpha`, `beta`, `rc` (versión preliminar de SemVer después de `-`) |\n`github.com/go-chi/chi@v5.0.0-rc1`, , `google.golang.org/grpc@v1.60.0-beta.1`, `github.com/octo-org/octo-module@v0.17.0-alpha.1` |\n\\| |\n\\| Bazel | `bazel` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`rules_go@0.46.0-rc1`, , `rules_rust@0.40.0-beta`, `bazel_skylib@1.5.0-alpha` |\n\\| |\n\\| Bun | `bun` |\n`alpha`, `beta`, `rc`, `canary` (versión preliminar de SemVer después de `-`) |\n`bun@1.0.0-beta.1`, , `elysia@1.0.0-rc.3`, `hono@4.0.0-canary.1` |\n\\| Composer | `composer` |\n`dev`, `alpha`, `a`, `beta`, `b`, `RC` (no distingue entre mayúsculas y minúsculas) |\n`laravel/framework@11.0.0-alpha1`, , `symfony/console@7.0.0-beta2`, `monolog/monolog@3.0.0-RC1` |\n\\| |\n\\| Conda | `conda` |\n`dev`, `alpha`, `a`, `beta`, `b`, `rc`, , `c``post` |\n`numpy@2.0.0a1`, `pandas@2.1.0b2`, , `scipy@1.12.0rc1`, `scikit-learn@1.4.0.dev0` |\n\\| |\n\\| |\n\\| Deno | `deno` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`oak@13.0.0-alpha`, , `fresh@2.0.0-rc.1`, `std@0.220.0-beta.2` |\n\\| |\n\\| Contenedores de desarrollo | `devcontainers` | SemVer 2.0.0 (versión preliminar no usada en la práctica) |\n`ghcr.io/devcontainers/features/node@1.6.1`, `ghcr.io/devcontainers/features/python@1.6` |\n\\| SDK de .NET | `dotnet-sdk` |\n`preview.N`, , `rc.N`, `alpha.N` |\n`dotnet-sdk@9.0.100-preview.7.24407.12`, `dotnet-sdk@9.0.100-rc.2.24474.11` |\n\\| GitHub Actions | `github-actions` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`my-org/my-action@v1.0.0-beta.1`, , `my-org/deploy@v2.0.0-rc1`, `my-org/lint@v3.0.0-alpha` |\n\\| |\n\\| Gráficos de Helm | `helm` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`ingress-nginx@4.11.0-beta.0`, , `cert-manager@1.15.0-alpha.1`, `prometheus@25.0.0-rc1` |\n\\| |\n\\| Hex | `mix` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`, `dev`) |\n`phoenix/phoenix@1.7.0-rc.0`, , `elixir-ecto/ecto@3.11.0-beta.1`, `elixir-plug/plug@1.15.0-alpha.1` |\n\\| |\n\\| Julia | `julia` | Cualquier identificador de versión preliminar de SemVer (normalmente `rc`, `DEV`, `beta`) |\n`HTTP@1.10.0-rc1`, , `Plots@2.0.0-DEV`, `DataFrames@1.6.0-beta.1` |\n\\| |\n\\| |\n\\| Nix | `nix` | Ninguno: realiza un seguimiento de las confirmaciones de entrada de flake (sin esquema de control de versiones). |\n`nixpkgs@a1b2c3d`, , `devenv@e4f5a6b`, `flake-utils@c7d8e9f` |\n\\| |\n\\| NuGet | `nuget` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`, `preview`) |\n`Newtonsoft.Json@13.0.0-rc1`, , `Microsoft.Extensions.Hosting@8.0.0-preview.7`, `Serilog@3.0.0-beta.1` |\n\\| |\n\\| OpenTofu | `opentofu` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`opentofu/aws@5.0.0-alpha`, , `opentofu/google@5.0.0-rc1`, `opentofu/azurerm@4.0.0-beta1` |\n\\| |\n\\| |\n\\| pre-commit | `pre-commit` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`pre-commit/mirrors-mypy@1.10.0a1`, , `psf/black@24.1.0rc1`, `astral-sh/ruff-pre-commit@0.4.0-beta.1` |\n\\| |\n\\| Bar | `pub` | Cualquier identificador de versión preliminar de SemVer (normalmente `dev`, `beta`, `rc`) |\n`flutter/dio@5.0.0-dev.1`, , `dart-lang/http@1.2.0-beta.1`, `invertase/melos@4.0.0-rc.1` |\n\\| |\n\\| Cadena de herramientas de Rust | `rust-toolchain` | Basado en canales: `stable`, `beta`, `nightly` (no es un prelanzamiento de SemVer) |\n`rust@1.78.0`, `rust@beta`, , `rust@nightly`, `rust@nightly-2024-01-15` |\n\\| |\n\\| Swift | `swift` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`vapor/vapor@5.0.0-beta.1`, , `apple/swift-nio@3.0.0-rc1`, `pointfreeco/swift-composable-architecture@2.0.0-alpha.1` |\n\\| Terraform | `terraform` | Cualquier identificador de versión preliminar de SemVer (normalmente `alpha`, `beta`, `rc`) |\n`hashicorp/aws@5.0.0-rc1`, , `hashicorp/google@4.0.0-alpha`, `hashicorp/azurerm@3.0.0-beta1` |\n\\| ultravioleta | `uv` |\n`a`, `b`, `rc`, , `dev`( `post` PEP 440) |\n`requests@1.0.0a1`, `numpy@2.0.0b3`, `django@4.0rc1`, , `black@1.0.0.dev5`, `pandas@2.0.5.post1` |\n\\| |\n\\| vcpkg | `vcpkg` | Cualquier identificador de versión preliminar de SemVer (normalmente `beta`, `rc`) |\n`zlib@1.3.1-beta1`, , `openssl@3.2.0-rc.1`, `fmt@10.2.0-beta` |\n\\| |\n\n#### Detalles de control de versiones específicos del ecosistema\n\nEn los detalles siguientes se describe cómo Dependabot interpreta el control de versiones para ecosistemas específicos.\n\n* **Bundler:** No utiliza un conjunto fijo de etiquetas de prelanzamiento. Cualquier segmento de versión que contenga una letra se trata como versión preliminar (por ejemplo, `.alpha`, `.beta1`, `.rc2`). Los guiones se normalizan internamente como `.pre.` (por ejemplo, `1.0.0-beta` se convierte en `1.0.0.pre.beta`).\n\n* **Carga:** Sigue las convenciones de SemVer 2.0.0. Todo lo que aparece después de `-` es un identificador de versión preliminar (separado por puntos, `[0-9A-Za-z-]`). Se permiten metadatos de compilación (`+...`), pero se ignoran a efectos de precedencia.\n\n* **Gradle:** Además de los calificadores enumerados en la tabla, se reconocen estos alias: `pr`/`pre`/`preview`→`rc`,`eap`/`ea` →.`alpha` Entre los calificadores de versión preliminar adicionales se incluyen `dev`, `experimental` y `unstable`. Los calificadores se ordenan por precedencia: `alpha`/`a` < `beta`/`b` < `milestone`/`m` < `rc`/`cr` < `snapshot`< (vacío/`ga`/`final`/`release`) < . `sp` Los identificadores de forma libre que no están en esta lista se tratan como estables.\n\n* **pip/pipenv/pip-compile/poetry (PEP 440):** La tabla enumera los sufijos canónicos previos y posteriores al lanzamiento. Los alias también se reconocen y normalizan (`alpha`→`a`, `beta`→`b`,`c`/`pre`/`preview` →`rc`,`rev`/`r` →).`post` Las versiones de época (`N!...`) y las versiones locales (`+local`) se admiten; los segmentos locales solo se usan para interrumpir los vínculos cuando la versión pública es idéntica.\n\n* **Elm:** Impone un SemVer estricto (`MAJOR.MINOR.PATCH` solo con números enteros). El registro de paquetes elm no permite publicar versiones preliminares.\n Dependabot compara las versiones numéricamente.\n\n* **Módulos de Go:** sigue a SemVer con un prefijo obligatorio `v` . Las pseudo-versiones (`v0.0.0-YYYYMMDDHHMMSS-commithash`) representan confirmaciones no publicadas y siempre se tratan como versión preliminar. El sufijo `+incompatible` marca los módulos con versión principal 2 o superior sin archivo `go.mod` y no afecta al orden de las versiones.\n\n* \\*\\*submódulo git:\\*\\*Dependabot realiza un seguimiento de la confirmación más reciente en la rama configurada. No se comparan versiones: las actualizaciones siempre avanzan el SHA fijado. Si el submódulo realiza un seguimiento de una etiqueta, Dependabot sigue la confirmación de la etiqueta.\n\n* **Bazel:** Sigue las convenciones de versión preliminar de SemVer. El sufijo `.bcr.N` de Bazel Central Registry (BCR) se elimina antes de la comparación y no afecta a la detección de versiones preliminares.\n\n* **Deno:** Sigue las convenciones de versión preliminar de SemVer. Los metadatos de compilación (`+...`) se admiten, pero se ignoran al determinar la precedencia de la versión.\n\n* **Bun:** Sigue las convenciones de SemVer para versiones preliminares al estilo de npm. Los metadatos de compilación (`+...`) se admiten, pero se ignoran al determinar la precedencia de la versión.\n\n* \\*\\*GitHub Actions:\\*\\*Dependabot determina las versiones de la acción a partir de las etiquetas de Git. Cualquier etiqueta con un identificador de prelanzamiento de SemVer (cualquier cosa después de `-`) se considera de prelanzamiento. Además, las versiones marcadas como versión preliminar a través de la API de versión de GitHub se reconocen independientemente del formato de etiqueta.\n\n* **Julia:** Sigue las convenciones de versión preliminar de SemVer. Los identificadores de versión preliminar distinguen mayúsculas de minúsculas (por ejemplo, `DEV` y `dev` son distintos).\n\n* **Hex:** Sigue las convenciones de SemVer para versiones preliminares. Cualquier identificador después de `-` se considera una versión preliminar.\n\n* \\*\\*Nix:\\*\\*Dependabot realiza un seguimiento de las confirmaciones de entrada de flake, similares a los submódulos de Git. Internamente, las versiones se representan como pseudo-versiones (`0.0.0-0.N`). No hay una comparación tradicional entre versiones; las actualizaciones pasan al commit upstream más reciente.\n\n* **NuGet:** Sigue las convenciones de versión preliminar de SemVer 2.0.0. Los metadatos de compilación (`+...`) se admiten, pero se ignoran al determinar la precedencia de la versión.\n\n* **OpenTofu:** Sigue las convenciones de versión preliminar de SemVer (igual que Terraform). Los metadatos de compilación (incluido el `+backport` sufijo) se quitan antes de la comparación y no afectan a la detección de versiones preliminares.\n\n* **Cadena de herramientas de Rust:** Usa el control de versiones basado en canales (`stable`, `beta`, `nightly`) en lugar de los identificadores de versión preliminar de SemVer.\n Dependabot Actualiza el canal fijado o la versión nocturna con marca de fecha (por ejemplo, `nightly-2024-01-15`) a la última disponible.\n\n* **Terraform:** Sigue las convenciones de versión preliminar de SemVer. El `v` prefijo se quita antes de la comparación. Los metadatos de compilación (`+...`) se ignoran para la precedencia de versiones.\n\n* **Composer:** Sigue las convenciones de estabilidad de PHP Composer (sin distinción entre mayúsculas y minúsculas). Las marcas de estabilidad (`@dev`, `@beta`) en las restricciones se quitan antes de la comparación. El `v` prefijo se controla de forma transparente.\n\n* **Conda:** Sigue la especificación de versiones de conda (similar a PEP 440). Se admiten versiones de época (`N!...`) y versiones locales (`+local`). Se reconocen los sufijos de pospublicación (`post`).\n\n* **.NET SDK:** los identificadores de versión preliminar siguen el patrón `preview.N`, `rc.N`, `alpha.N`. Las actualizaciones preliminares requieren `allowPrerelease: true` en `global.json`.\n\n* **Helm Charts:** Sigue las convenciones de prerelease de SemVer. Los prefijos de versión de los charts (por ejemplo, `chart-v`) y los resúmenes de compilación (`+sha256:...`) se eliminan antes de la comparación.\n\n* **pre-commit:** Resuelve las versiones de los hooks a partir de las etiquetas de Git. La detección de versiones de prelanzamiento usa tanto la heurística de Gem::Version como el indicador `prerelease` de la API de GitHub Release. También se admiten los hooks con SHA fijado.\n\n* **Pub:** Sigue las convenciones de versión preliminar de SemVer. Los metadatos de compilación (`+...`) se admiten, pero se ignoran al determinar la precedencia de la versión.\n\n* **Swift:** Sigue las convenciones de prelanzamiento de SemVer. El filtrado de versión preliminar no se aplica actualmente; todas las versiones se tratan igualmente en comparación.\n\n* **vcpkg:** Admite varios formatos de versión: numéricos separados por puntos, SemVer (sin metadatos de compilación) y basados en fechas. El sufijo de la versión del puerto (`#N`) indica las revisiones del paquete y no afecta a la detección de versiones preliminares.\n\n#### Glosario de etiquetas de control de versiones\n\n* **`alpha`:** la versión temprana, puede ser inestable y tener características incompletas.\n* **`beta`:** más estable que alfa, pero todavía puede tener errores.\n* **`canary`:** se actualiza periódicamente la versión preliminar para las pruebas.\n* **`dev`:** representa las versiones de desarrollo.\n* **`experimental`:** versiones con características experimentales.\n* **`latest`:** la versión estable más reciente.\n* **`legacy`:** versiones anteriores o en desuso.\n* **`next`:** la próxima versión de lanzamiento.\n* **`nightly`:** versiones compiladas por la noche; a menudo incluye los cambios más recientes.\n* **`rc`:** versión candidata para lanzamiento, cerca de la versión estable.\n* **`release`:** la versión de lanzamiento oficial.\n* **`stable`:** la versión más fiable y lista para producció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 | Propósito |\n| :----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `REGISTRY_NAME` | |\n| **Obligatorio:** define un identificador para el registro. | |\n| `type` | |\n| **Obligatorio:** identifica el tipo de registro. | |\n| Detalles de la autenticación | |\n| **Obligatorio:** los parámetros admitidos para proporcionar detalles de autenticación varían para los registros de diferentes tipos. | |\n| `url` | |\n| **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://`. | |\n| Dependabot añade u omite las barras finales según sea necesario. | |\n| `replaces-base` | Si el valor booleano es `true`, Dependabot resuelve las dependencias mediante el especificado `url` en lugar de la dirección URL base de ese ecosistema. |\n| | |\n| `scope` | Solo para el tipo `npm-registry`. Ámbito de npm que se va a asociar a este registro, por ejemplo `@my-company`. Cuando se proporciona `scope`, Dependabot genera la configuración `.npmrc` a partir de las credenciales del registro, anulando cualquier archivo `.npmrc` confirmado o la inferencia a partir del archivo de bloqueo. |\n| | |\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries).\n\n### `type` y detalles de autenticació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| `username` y `password` o OIDC con `tenant-id` y `client-id` | |\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/configure-access-to-private-registries).\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/configure-access-to-private-registries#using-oidc-for-authentication).\n\n### `url` y `replaces-base`\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.\n\n### `scope`\n\nEl parámetro `scope` está disponible en los registros de tipo `npm-registry`. Especifica qué ámbito de npm se debe asociar al registro. El valor debe comenzar con `@`, por ejemplo `@my-company`. Para asociar varios ámbitos a la misma dirección URL del Registro, cree una entrada del Registro independiente para cada ámbito.\n\nCuando se proporciona `scope`, Dependabot genera la configuración `.npmrc` a partir de las credenciales del registro. Esta configuración generada tiene prioridad sobre cualquier archivo `.npmrc` confirmado o sobre cualquier inferencia basada en archivos de bloqueo.\n\n#### Orden de prioridad para la resolución del registro de npm\n\nAl determinar qué registro se va a usar para las dependencias de npm, Dependabot sigue este orden de prioridad:\n\n1. **Generación basada en credenciales (`scope` o `replaces-base`):** si `scope` o `replaces-base` está configurado en cualquier `npm-registry` credencial de `dependabot.yml`, Dependabot genera a `.npmrc` partir de esas credenciales. Esto siempre tiene prioridad y anula cualquier archivo `.npmrc` ya confirmado.\n2. **Confirmado `.npmrc` en el repositorio:** Si no se establece `scope`, Dependabot usa cualquier archivo `.npmrc` confirmado en el repositorio.\n3. **Inferencia del archivo de bloqueo (transicional):** Si no hay `scope` y no hay ningún `.npmrc` confirmado, Dependabot intenta inferir la configuración del registro a partir del archivo de bloqueo.\n4. **Generación de errores:** Si ninguno de los métodos anteriores se realiza correctamente, Dependabot notifica un error con instrucciones para agregar una configuración explícita."}