# Personalización de las pull requests de Dependabot para adaptarlas a tus procesos

Aprende a adaptar las solicitudes de cambios de Dependabot para ajustarlas mejor a tus propios flujos de trabajo internos.

Hay varias maneras de personalizar las solicitudes de incorporación de cambios de Dependabot para que se adapten mejor a sus propios procesos internos.

Por ejemplo, para integrar las solicitudes de incorporación de cambios de Dependabot en las canalizaciones de CI/CD, puede aplicar **etiquetas personalizadas** a las solicitudes de incorporación de cambios, que después puede usar para desencadenar flujos de trabajo de acción.

Hay varias opciones de personalización diferentes que se pueden usar de manera conjunta, adaptadas a cada ecosistema de paquetes.

## Adición automática de usuarios asignados

De forma predeterminada, Dependabot genera solicitudes de extracción sin ninguna persona asignada.

Para asignar automáticamente solicitudes de incorporación de cambios a un equipo de seguridad designado, puedes usar `assignees` para establecer estos valores por ecosistema de paquetes.

En el archivo `dependabot.yml` de ejemplo siguiente se cambia la configuración de npm para que todas las solicitudes de cambios que se hayan abierto con actualizaciones de versión y seguridad para npm tengan lo siguiente:

* Un individuo ("`user-name`") asignado automáticamente a las solicitudes de cambios.

```yaml copy
# `dependabot.yml` file with
#  assignee for all npm pull requests

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise all npm pull requests with assignees
    assignees:
      - "user-name"
```

## Adición automática de revisores

De forma predeterminada, Dependabot genera solicitudes de incorporación de cambios sin revisores.

Para asegurarse de que el equipo adecuado soluciona rápidamente las actualizaciones de seguridad del proyecto, puede agregar automáticamente revisores a las solicitudes de incorporación de cambios de Dependabot mediante un archivo CODEOWNERS. Consulta [Acerca de los propietarios de código](/es/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

## Etiquetado de solicitudes de cambios con etiquetas personalizadas

De forma predeterminada, Dependabot genera solicitudes de extracción con la etiqueta `dependencies`.

Dependabot también aplica una etiqueta del ecosistema, como `java`, `npm`o `github-actions`, a las solicitudes de incorporación de cambios.
Dependabot agrega tanto la etiqueta `dependencies` como la etiqueta del ecosistema a todas las solicitudes de extracción, incluidas las actualizaciones de un solo ecosistema, para mejorar el filtrado y el triaje.

Dependabot crea las etiquetas predeterminadas que aplica a las solicitudes de extracción si aún no existen en el repositorio. Si quiere usar etiquetas personalizadas en lugar de los valores predeterminados, puede establecer la opción `labels` en su archivo `dependabot.yml` por ecosistema de paquetes; esto sobrescribe los valores predeterminados. Para obtener más información, consulta [Administrar las etiquetas](/es/issues/using-labels-and-milestones-to-track-work/managing-labels) y [`labels`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#labels--).

Si las etiquetas de versión semántica (SemVer) están presentes en el repositorio, Dependabot también las aplicará automáticamente para indicar el tipo de actualización de versión (`major`, `minor`o `patch`). Estas etiquetas se aplican además de las etiquetas personalizadas que defina.

Puedes usar `labels` para invalidar las etiquetas predeterminadas y especificar etiquetas personalizadas propias para cada ecosistema de paquetes. Esto es útil, por ejemplo, si quieres:

* Use etiquetas para asignar una prioridad a determinadas solicitudes de incorporación de cambios.
* Usar etiquetas para desencadenar otro flujo de trabajo, como agregar automáticamente el pull request a un tablero de proyecto.

El archivo `dependabot.yml` de ejemplo mostrado a continuación cambia la configuración de npm para que todas las solicitudes de incorporación de cambios que se hayan abierto con actualizaciones de versión y seguridad para npm tengan etiquetas personalizadas.

```yaml copy
# `dependabot.yml` file with
# customized npm configuration

version: 2
updates:
  # Keep npm dependencies up to date
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise all npm pull requests with custom labels
    labels:
      - "npm dependencies"
      - "triage-board"
```

Configurar 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.

Consulte también [`labels`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#labels--).

## Adición de un prefijo a los mensajes de confirmación

De forma predeterminada, Dependabot intenta detectar las preferencias del mensaje de confirmación y usar patrones similares. Además, Dependabot rellena los títulos de las solicitudes de incorporación de cambios en función de los mensajes de confirmación.

Puede especificar su propio prefijo para los mensajes de confirmación de Dependabot (y títulos de solicitud de incorporación de cambios) para un ecosistema de paquetes específico. Esto puede ser útil si, por ejemplo, vas a ejecutar automatizaciones que procesan mensajes de confirmación o títulos de solicitudes de cambios.

Para especificar explícitamente tus preferencias, usa `commit-message` junto con las siguientes opciones admitidas:

* `prefix`:
  * especifica un prefijo para todos los mensajes de confirmación.
  * El prefijo también se agrega al inicio del título del pull request.
* `prefix-development`:
  * especifica un prefijo independiente para todos los mensajes de confirmación que actualizan las dependencias de desarrollo, en función de lo definido por el administrador de paquetes o el ecosistema.
  * Compatible con `bundler`, `composer`, `mix`, `maven`, `npm`, `pip`, y `uv`.
* `include: "scope"`:
  * Especifica que cualquier prefijo va seguido de los tipos de dependencias (`deps` o `deps-dev`) actualizadas en la confirmación.

En el ejemplo siguiente se muestran varias opciones diferentes, adaptadas para cada ecosistema de paquetes:

```yaml copy
# Customize commit messages

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "npm: "
      prefix: "npm"

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      # Prefix all commit messages with "[docker] " (no colon, but a trailing whitespace)
      prefix: "[docker] "

  - package-ecosystem: "composer"
    directory: "/"
    schedule:
      interval: "weekly"
    # Prefix all commit messages with "Composer" plus its scope, that is, a
    # list of updated dependencies
    commit-message:
      prefix: "Composer"
      include: "scope"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Include a list of updated dependencies
    # with a prefix determined by the dependency group
    commit-message:
      prefix: "pip prod"
      prefix-development: "pip dev"
```

Configurar 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.

Consulte también [`commit-message`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#commit-message--).

## Asociación de solicitudes de incorporación de cambios con un hito

Los hitos ayudan a realizar el seguimiento del progreso de grupos de solicitudes de incorporación de cambios (o incidencias) hacia un objetivo o una versión del proyecto. Con Dependabot, puede usar la opción `milestone` para asociar solicitudes de incorporación de cambios para las actualizaciones de dependencia con un hito específico.

Debes especificar el identificador numérico del hito y no su etiqueta. Para buscar el identificador numérico, comprueba la parte final de la dirección URL de la página, después de `milestone`. Por ejemplo, para `https://github.com/<org>/<repo>/milestone/3`, "`3`" es el identificador numérico del hito.

```yaml copy
# Specify a milestone for pull requests

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Associate pull requests with milestone "4"
    milestone: 4
```

Configurar 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.

Consulta también [`milestone`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#milestone--) y [Acerca de los hitos](/es/issues/using-labels-and-milestones-to-track-work/about-milestones).

## Personalizar los nombres de las ramas de las pull requests

Dependabot genera una rama para cada solicitud de incorporación de cambios. Cada nombre de rama incluye `dependabot`, así como el nombre del administrador de paquetes y la dependencia que se va a actualizar. De manera predeterminada, estas partes del nombre de la rama están separadas por un símbolo `/`, por ejemplo:

* `dependabot/npm_and_yarn/next_js/acorn-6.4.1`

Puede personalizar los nombres de rama mediante la `pull-request-branch-name` opción con los parámetros siguientes: `separator`, `prefix`, `max-length`, `word-separator`, `branch-name-case`y `template`. Todas las opciones se pueden combinar entre sí, y puedes combinar cualquiera de ellas. Para obtener la referencia completa de cada parámetro, consulte [`pull-request-branch-name`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#pull-request-branch-name--).

### Combinación de opciones de formato

Puede combinar `separator`, `word-separator`, `branch-name-case`, `max-length`y `template` para generar nombres de rama que cumplan los requisitos del sistema. Por ejemplo, compatibilidad de etiquetas de Docker, nombres de Azure Container Registry o límites de longitud de rama de Kubernetes.

Cuando `template` se configura junto con otras opciones, el formato se aplica en una fase de posprocesamiento después del procesamiento de la plantilla, en este orden: reemplazo del separador, reemplazo del separador de palabras, cambio entre mayúsculas y minúsculas y, por último, truncamiento a la longitud máxima.

```yaml copy
# Combine template with formatting options

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
      max-length: 80
```

* **Antes** (valor predeterminado): `dependabot/npm_and_yarn/Lodash-4.17.21`
* **Después** (con la configuración anterior): `dependabot-npm-and-yarn-lodash-4.17.21`

Cuando un nombre de rama supera `max-length`, se trunca con un sufijo hash para conservar la unicidad.

### Ejemplo completo con grupos de varios ecosistemas

A continuación se `dependabot.yml` muestran todas las opciones disponibles en distintos ecosistemas, incluida la configuración de grupos de varios ecosistemas:

```yaml copy
# Full example demonstrating all branch name options

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      template: "{prefix}/infra/{name}"
      word-separator: "-"
      branch-name-case: "lowercase"

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      separator: "-"
      word-separator: "-"
      branch-name-case: "lowercase"
    groups:
      frontend-deps:
        patterns: ["react*", "next*"]

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "monthly"
    pull-request-branch-name:
      template: "{prefix}/{package_manager}/{dependency}-{version}"
      max-length: 60

  - package-ecosystem: "pip"
    directory: "/backend"
    schedule:
      interval: "weekly"
    pull-request-branch-name:
      prefix: "deps"
      branch-name-case: "lowercase"
    groups:
      django-deps:
        patterns: ["django*"]

  # These entries participate in the "infrastructure" multi-ecosystem group
  - package-ecosystem: "docker"
    directory: "/infra"
    patterns: ["nginx", "redis", "postgres"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/infra"
    patterns: ["hashicorp/*"]
    multi-ecosystem-group: "infrastructure"
```

Esta configuración genera los siguientes nombres de rama:

| Escenario                                                       | Strategy           | Nombre de rama                                     |
| --------------------------------------------------------------- | ------------------ | -------------------------------------------------- |
| actualización de lodash en npm                                  | Solo               | `dependabot-npm-and-yarn-lodash-4.17.21`           |
| Actualización del grupo frontend-deps en npm                    | Agrupado           | `dependabot-npm-and-yarn-frontend-deps-fc93691fd4` |
| actualización de nginx solo en Docker                           | Solo               | `dependabot/docker/nginx-1.25.0`                   |
| actualizar Django con pip                                       | Solo               | `deps/pip/django-4.2.1`                            |
| actualización del grupo pip django-deps                         | Agrupado           | `deps/pip/django-deps-a1b2c3d4e5`                  |
| Grupo de infraestructura entre ecosistemas (Docker + Terraform) | Varios ecosistemas | `dependabot/infra/infrastructure-fc93691fd4`       |

> \[!NOTE]
> Para grupos de varios ecosistemas:
>
> * El `pull-request-branch-name` de la entrada `multi-ecosystem-groups` controla el nombre de la rama de PR agrupada entre ecosistemas.
> * Las entradas individuales `updates` que especifiquen `multi-ecosystem-group`**no pueden** tener su propio `pull-request-branch-name`. La configuración de nivel de grupo tiene prioridad y es la única que se usa para esas entradas.
> *

`{package_manager}` no está disponible en plantillas de grupo de varios ecosistemas porque el grupo abarca varios ecosistemas.

> * Un resumen de contenido siempre se anexa automáticamente a las ramas de grupos de varios ecosistemas para garantizar la unicidad.

### Cómo se aplica la configuración del nombre de rama

* **La configuración es por entrada de actualización**: cada entrada independiente `package-ecosystem` puede tener su propia configuración de nombre de rama. Las entradas asignadas a un grupo de varios ecosistemas usan la configuración de nivel de grupo en su lugar.
* **Las solicitudes de incorporación de cambios existentes no se ven afectadas**: los cambios solo se aplican a las solicitudes de incorporación de cambios recién creadas.
* **El comportamiento predeterminado no se modifica**: si no configura ninguna opción, los nombres de rama permanecen exactamente como están actualmente.

Configurar 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.

## Selección de destino de pull requests en una rama no por defecto

De forma predeterminada, Dependabot busca archivos de manifiesto en la rama predeterminada y crea solicitudes de incorporación de cambios para aplicar actualizaciones a la rama predeterminada.

Por lo general, tiene más sentido mantener sus comprobaciones y actualizaciones en la rama predeterminada de Dependabot. Pero es posible que haya casos en los que quieras especificar otra rama de destino. Si, por ejemplo, los procesos de su equipo requieren probar y validar primero las actualizaciones en una rama de no producción, puede usar `target-branch` para especificar una rama diferente para que Dependabot cree solicitudes de extracción dirigidas a ella.

> \[!NOTE]
> Dependabot genera solicitudes de incorporación de cambios para las actualizaciones de seguridad solo en la **rama predeterminada**. Si usas `target-branch`, como resultado, todas las opciones de configuración de ese administrador de paquetes *solo* se aplicarán a las actualizaciones de versión y no a las actualizaciones de seguridad.

```yaml copy
# Specify a non-default branch for pull requests for pip

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    # Raise pull requests for version updates
    # to pip against the `develop` branch
    target-branch: "develop"
    # Labels on pull requests for version updates only
    labels:
      - "pip dependencies"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      # Check for npm updates on Sundays
      day: "sunday"
    # Labels on pull requests for security and version updates
    labels:
      - "npm dependencies"
```

Consulte también [`target-branch`](/es/code-security/reference/supply-chain-security/dependabot-options-reference#target-branch-).