Proyecto integrador

Llegó el momento de juntar todo. Vamos a armar el .github/ completo de un proyecto ficticio pero realista: acme-api, una API en Node.js. Cada archivo que agreguemos corresponde a algo que ya vimos en el curso; al final tenés un .github que podés adaptar a tus propios repos casi tal cual.

El árbol final

flowchart TD
    G[".github/"]
    G --> WF["workflows/"]
    WF --> CI["ci.yml"]
    WF --> REL["release.yml"]
    G --> ACT["actions/setup-node/action.yml"]
    G --> IT["ISSUE_TEMPLATE/"]
    IT --> BUG["bug_report.yml"]
    IT --> CFG["config.yml"]
    G --> PRT["PULL_REQUEST_TEMPLATE.md"]
    G --> CO["CODEOWNERS"]
    G --> SEC["SECURITY.md"]
    G --> CONTRIB["CONTRIBUTING.md"]
    G --> FUND["FUNDING.yml"]
    G --> DEP["dependabot.yml"]
    G --> LAB["labeler.yml"]
    G --> RD["release-drafter.yml"]
    G --> COP["copilot-instructions.md"]

Recorrido archivo por archivo

Archivo	Qué resuelve	Capítulo
workflows/ci.yml	Corre lint y tests en cada push y PR	Cap. 2
workflows/release.yml	Publica releases al taggear	Cap. 3
actions/setup-node/action.yml	Composite action reutilizable para preparar Node	Cap. 4
Permisos de GITHUB_TOKEN en los workflows	Principio de mínimo privilegio	Cap. 6
ISSUE_TEMPLATE/bug_report.yml	Formulario guiado para reportar bugs	Cap. 10
ISSUE_TEMPLATE/config.yml	Enlaces externos y config del selector de issues	Cap. 10
PULL_REQUEST_TEMPLATE.md	Descripción de PR precompletada con checklist	Cap. 11
CODEOWNERS	Revisores automáticos por rutas	Cap. 8
SECURITY.md	Política de reporte de vulnerabilidades	Cap. 9
CONTRIBUTING.md	Cómo contribuir al proyecto	Cap. 7
FUNDING.yml	Botón de patrocinio del repo	Cap. 7
dependabot.yml	Version updates de npm y github-actions	Cap. 12
labeler.yml	Etiquetado automático de PRs por archivos	Cap. 13
release-drafter.yml	Draft continuo de notas de release	Cap. 13
copilot-instructions.md	Contexto persistente para Copilot	Cap. 14

Cómo encaja todo

flowchart LR
    DEV["Contribuidor"] -->|abre issue| IT["ISSUE_TEMPLATE"]
    DEV -->|abre PR| PRT["PR template"]
    PRT --> CI["ci.yml corre<br/>lint + tests"]
    PRT --> LAB["labeler etiqueta"]
    PRT --> CO["CODEOWNERS<br/>pide review"]
    CI --> MERGE{"¿checks OK +<br/>review OK?"}
    CO --> MERGE
    MERGE -->|sí| MAIN["merge a main"]
    MAIN --> RD["release-drafter<br/>actualiza el draft"]
    DEP["dependabot"] -.->|PRs periódicos| CI

Un contribuidor abre una issue con el formulario guiado o un PR con la descripción precompletada. Al abrir el PR, CI corre lint y tests, labeler lo etiqueta y CODEOWNERS pide la review de quien corresponde. Cuando pasan los checks y las aprobaciones, se mergea a main, y ahí release-drafter actualiza el borrador de la próxima release. En paralelo, Dependabot abre PRs para mantener todo al día. Nadie coordina esto a mano: lo hace el .github.

Checklist final

Antes de dar por terminado tu .github, repasá cada decisión clave del curso:

• ¿ci.yml corre lint y tests en push y pull_request a la rama principal?
• ¿Configuraste permisos mínimos de GITHUB_TOKEN (permissions:) en cada workflow, en vez de dejar los amplios por defecto?
• ¿Fijaste las Actions de terceros a un SHA o versión concreta en lugar de una rama móvil?
• ¿Extrajiste la lógica repetida (setup de Node) a una composite action reutilizable?
• ¿Tenés ISSUE_TEMPLATE/bug_report.yml y un config.yml que apunte a los canales correctos?
• ¿El PULL_REQUEST_TEMPLATE.md incluye una checklist corta y accionable?
• ¿Tenés CODEOWNERS con “Require review from Code Owners” activado en la branch protection?
• ¿SECURITY.md describe cómo reportar una vulnerabilidad de forma privada?
• ¿Incluiste los community health files básicos (CONTRIBUTING.md, CODE_OF_CONDUCT.md)?
• ¿dependabot.yml cubre todos los ecosistemas de tu stack, incluyendo github-actions?
• ¿Usaste groups en Dependabot para no ahogarte en PRs sueltos?
• ¿Verificaste que las security updates estén activas (por defecto en repos públicos)?
• ¿labeler.yml mapea rutas a labels útiles para tu flujo?
• ¿copilot-instructions.md tiene los comandos exactos de build/test y tus convenciones?
• ¿Preferiste Actions oficiales de GitHub sobre apps de terceros donde había opción?

Cierre del curso

¡Felicitaciones por llegar hasta acá! Recorriste toda la carpeta .github de punta a punta: desde los fundamentos de Actions y sus triggers, pasando por seguridad, workflows reutilizables, community health files, CODEOWNERS, SECURITY, templates, Dependabot y la automatización del repositorio, hasta el contexto persistente para Copilot. Ahora tenés las piezas y, más importante, el criterio para decidir cuáles usar y por qué. El mejor siguiente paso es aplicarlo: tomá un repo real, armá su .github con este checklist a mano y ajustalo a tu contexto. La plataforma trabaja para vos cuando le decís, con archivos en el lugar correcto, cómo querés que trabaje.

---

Anterior → Capítulo 14: GitHub Copilot

¿Querés repasar algún tema? Volvé al Índice y elegí el capítulo que quieras revisitar.