actions/labeler

Qué es

actions/labeler es una GitHub Action oficial, mantenida por la organización actions de GitHub, que añade etiquetas a las pull requests de forma automática. Decide qué etiquetas aplicar a partir de las rutas de los archivos modificados o del nombre de la rama, usando un archivo de configuración en el repositorio. Está escrita en TypeScript y se publica bajo licencia MIT.

Para qué sirve

• Etiquetar PRs por área del código (por ejemplo documentación, frontend, tests) según los archivos que tocan.
• Marcar PRs según el nombre de la rama de origen o de destino (por ejemplo feature, release).
• Mantener el triaje de PRs ordenado sin intervención manual del equipo.
• Disparar acciones posteriores en el workflow usando las etiquetas calculadas como salida.

Cuándo usarlo

Es ideal en repositorios con flujo activo de pull requests donde el etiquetado manual es tedioso o inconsistente. Encaja bien para automatizar el triaje por carpetas o por convención de ramas. Si necesitas etiquetar issues además de PRs, o reglas más complejas basadas en contenido, conviene combinarlo con otras actions de la comunidad o con scripts propios.

Ejemplo

Workflow en .github/workflows/labeler.yml:

name: 'Pull Request Labeler'
on:
  - pull_request_target

jobs:
  labeler:
    permissions:
      contents: read
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v6

Configuración en .github/labeler.yml:

documentación:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'guides/**']

feature:
  - head-branch: ['^feature', 'feature']

release:
  - base-branch: 'main'

Puntos clave

• Reglas por glob con operadores como any-glob-to-any-file o all-globs-to-all-files.
• Coincidencia por rama base (base-branch) y rama de origen (head-branch) mediante expresiones regulares.
• Combinación lógica de condiciones con any (OR) y all (AND).
• Sincronización opcional de etiquetas y salidas (new-labels, all-labels) para encadenar pasos.

Ten en cuenta

Para funcionar con PRs de forks suele usarse el evento pull_request_target, que ejecuta el workflow con permisos del repositorio base; revisa las implicaciones de seguridad antes de adoptarlo. La acción necesita el permiso pull-requests: write. Verifica la versión mayor que fijas (@v6), ya que entre versiones mayores ha habido cambios en el formato de configuración. Consulta el repositorio oficial para la sintaxis más actualizada.