Automatización de repo

Más allá de CI/CD y Dependabot, hay un conjunto de tareas de mantenimiento que se pueden automatizar: etiquetar PRs, redactar notas de release, cerrar issues abandonadas, mergear cuando pasan los checks, declarar la config del repo como código. Antes de ver cada una, la distinción que ordena todo el capítulo:

• (a) Actions oficiales de GitHub — nativas, mantenidas por GitHub, no instalás nada externo. Solo agregás un workflow que las usa.
• (b) Apps/bots de terceros — requieren instalar una GitHub App desde el Marketplace o correr una Action de un tercero. Aportan más flexibilidad, pero son código y permisos fuera de GitHub.

En cada sección marco explícitamente cuál es cuál.

Labeler — oficial (actions/labeler)

Aplica labels a los PRs automáticamente según qué archivos tocan. Se configura con .github/labeler.yml, donde la clave es el nombre del label a aplicar y el valor es un “match object” (por ejemplo, rutas de archivos modificados).

# .github/labeler.yml
frontend:
  - changed-files:
      - any-glob-to-any-file: "src/**/*.tsx"

documentación:
  - changed-files:
      - any-glob-to-any-file: "docs/**"

Se invoca desde un workflow disparado en pull_request:

# .github/workflows/labeler.yml
on: [pull_request]
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5

Release Drafter — terceros (release-drafter/release-drafter)

Redacta automáticamente las notas de release como un draft que se va actualizando cada vez que se mergea un PR a la rama por defecto. Cuando estás listo para publicar, la release ya está escrita. Originalmente era una Probot App; hoy también se puede correr como GitHub Action, por eso lo clasificamos como de terceros.

Se configura con .github/release-drafter.yml:

# .github/release-drafter.yml
name-template: "v$RESOLVED_VERSION"
tag-template: "v$RESOLVED_VERSION"
categories:
  - title: "Features"
    labels: ["feature", "enhancement"]
  - title: "Fixes"
    labels: ["fix", "bug"]
template: |
  ## Cambios
  $CHANGES

Las claves principales son template (cuerpo de la nota), name-template, tag-template y categories (agrupa los PRs por sus labels).

Stale issues/PRs — oficial y recomendado (actions/stale)

Marca y luego cierra issues/PRs inactivos tras un tiempo configurable. Corre como workflow programado (schedule), típicamente una vez por día.

# .github/workflows/stale.yml
on:
  schedule:
    - cron: "0 0 * * *"
jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          days-before-stale: 60
          days-before-close: 14
          exempt-issue-labels: "pinned,security"

days-before-stale es cuánto esperar antes de marcar como stale; days-before-close, cuánto más antes de cerrar; y con labels de exención (exempt-issue-labels) protegés lo que nunca debe cerrarse.

Nota histórica: la herramienta original para esto era probot/stale, una app de terceros. Está archivada y deprecada desde el 20 de mayo de 2023 — no la uses. La opción vigente y recomendada es la Action oficial actions/stale, que hace lo mismo sin instalar ninguna app externa.

Auto-merge — nativo de GitHub

La forma recomendada es la función Auto-merge, nativa de la plataforma. Se habilita por repo en Settings y se activa por PR con el botón “Enable auto-merge” o por CLI:

gh pr merge --auto --squash 123

GitHub mergea el PR automáticamente apenas se cumplen los checks requeridos y las aprobaciones necesarias. Para reglas más granulares existen alternativas de terceros como probot-auto-merge (configurable con .github/auto-merge.yml), pero la función nativa cubre el caso común sin instalar nada.

Settings-as-code — terceros (settings.yml)

Permite declarar la configuración del repo como código en .github/settings.yml: descripción, topics, labels y algunas branch protection rules. Cuando se mergea un cambio a ese archivo, la config se aplica automáticamente.

No es nativo de GitHub: requiere instalar la Probot Settings App (o su Action equivalente del Marketplace). Tenelo en cuenta, porque le estás dando a una app de terceros permiso para modificar la configuración de tu repositorio.

# .github/settings.yml
repository:
  description: "API de ejemplo"
  topics: nodejs, api
labels:
  - name: bug
    color: d73a4a

Resumen

Herramienta	Nativa vs terceros	Archivo de config	Qué resuelve
actions/labeler	Oficial	.github/labeler.yml	Etiquetar PRs por archivos tocados
Release Drafter	Terceros	.github/release-drafter.yml	Draft de notas de release
actions/stale	Oficial (recomendado)	Workflow con schedule	Cerrar issues/PRs inactivos
Auto-merge	Nativo (función)	— (Settings / por PR)	Mergear al pasar checks
Settings App	Terceros	.github/settings.yml	Config del repo como código

Recomendación práctica

Preferí siempre lo oficial cuando existe: actions/labeler, actions/stale y la función nativa de Auto-merge cubren la mayoría de las necesidades sin sumar apps de terceros con permisos amplios sobre tu repo. Reservá las herramientas de terceros para cuando de verdad necesites lo que ellas ofrecen y la opción nativa se quede corta.

---

Anterior → Capítulo 12: Dependabot · Siguiente → Capítulo 14: GitHub Copilot