INTEGRACIÓN GITHUB n8n: AUTOMATIZAR GITHUB CON N8N

Esta acción lista todos los workflows de Github Actions disponibles en un repositorio específico. Es particularmente útil cuando necesitas obtener información sobre los workflows configurados en tu repo para luego dispararlos, monitorear su estado o generar reportes de CI/CD. La acción devuelve detalles completos de cada workflow, incluyendo su ID, nombre, estado (activo/inactivo), y ruta del archivo YAML.

Parámetros clave: Repository Owner (Campo dropdown que selecciona el propietario del repositorio desde una lista vinculada a tu cuenta Github conectada. Requerido para identificar a quién pertenece el repo). Repository Name (Campo dropdown que selecciona el nombre del repositorio específico bajo el propietario elegido. Requerido para determinar de qué repo listar los workflows).

Casos de uso típicos: Obtener la lista de workflows disponibles antes de disparar uno específico con la acción "Dispatch", auditar qué workflows están activos en tus repositorios de producción, generar un inventario de pipelines CI/CD en tu organización Github.

Cuándo usarlo: Úsalo como paso previo antes de ejecutar workflows dinámicamente, o cuando necesites monitorear/reportar sobre la configuración de CI/CD de múltiples repositorios en tu organización.

Esta acción recupera las estadísticas de uso (consumo de minutos, almacenamiento, ejecuciones) de un workflow específico de Github Actions. Es ideal para monitorear el consumo de recursos de tus pipelines, identificar workflows costosos o generar reportes de usage para facturación interna o optimización de costos.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repositorio desde una lista. Requerido). Repository Name (Dropdown para seleccionar el repositorio específico. Requerido). Workflow (Dropdown para seleccionar el workflow del cual obtener estadísticas, mostrando workflows disponibles en el repo elegido. Requerido para identificar el workflow objetivo).

Casos de uso típicos: Monitorear mensualmente el consumo de minutos de Github Actions para controlar costos, identificar workflows que consumen recursos excesivos y optimizarlos, generar reportes automáticos de usage enviados a finanzas o DevOps leads.

Cuándo usarlo: Ideal para workflows de reporting periódico (diario, semanal, mensual) que monitorean el consumo de Github Actions, o cuando implementas alertas de costos para evitar sorpresas en la factura.

Obtiene información detallada sobre un workflow específico de Github Actions: nombre, ID, estado (enabled/disabled), ruta del archivo .yml, fecha de creación, última ejecución, etc. A diferencia de "List" que devuelve múltiples workflows, esta acción se centra en uno solo y proporciona datos más completos.

Parámetros clave: Repository Owner (Selección del propietario del repo desde lista. Requerido). Repository Name (Selección del repositorio desde lista. Requerido). Workflow (Selección del workflow específico desde lista de workflows disponibles. Requerido para identificar cuál workflow consultar).

Casos de uso: Verificar si un workflow está habilitado antes de intentar dispararlo, obtener el ID de un workflow para usarlo en otras acciones (Dispatch, Enable, Disable), auditar configuraciones de workflows críticos (fechas de última modificación, estado).

Cuándo usarlo: Antes de operar sobre un workflow (dispararlo, habilitarlo, deshabilitarlo), o cuando necesitas información detallada sobre un workflow para logging, auditoría o debugging.

Habilita un workflow de Github Actions que estaba previamente deshabilitado. Los workflows deshabilitados no se ejecutan automáticamente ni pueden ser disparados manualmente hasta que se reactiven. Esta acción es útil para reactivar pipelines pausados tras mantenimiento, testing o durante ventanas de despliegue controladas.

Parámetros clave: Repository Owner (Selección del propietario del repositorio desde lista. Requerido). Repository Name (Selección del repositorio desde lista. Requerido). Workflow (Selección del workflow a habilitar desde lista de workflows en el repo. Requerido para identificar el workflow objetivo).

Casos de uso: Reactivar workflows de producción después de una ventana de mantenimiento planificada, habilitar dinámicamente workflows según horarios (ej: activar deploys solo en horario laboral), restaurar workflows deshabilitados tras resolver incidentes o bugs en el pipeline.

Cuándo usarlo: En workflows de control que orquestan ventanas de despliegue, o cuando automatizas la gestión de pipelines según condiciones (horarios, aprobaciones, estados de sistemas externos).

Dispara un workflow de Github Actions con inputs personalizados y pausa la ejecución del workflow n8n hasta que el workflow de Github complete y llame de vuelta a n8n mediante un webhook. Esta acción genera dinámicamente una URL de webhook (resumeUrl) que debe pasarse al workflow de Github como input para que éste notifique a n8n cuando termine (éxito o fallo). Es la acción más avanzada para integrar n8n con Github Actions, permitiendo workflows síncronos donde n8n espera el resultado antes de continuar.

Parámetros clave: Repository Owner (Selección del propietario del repo desde lista. Requerido). Repository Name (Selección del repositorio desde lista. Requerido). Workflow (Selección del workflow a disparar. Requerido). Ref (Dropdown para seleccionar la rama, tag o commit SHA desde el cual ejecutar el workflow. Requerido para especificar el punto de referencia Git). Inputs (Campo JSON para pasar inputs personalizados al workflow. Aquí debes incluir el resumeUrl accesible vía expresión que el workflow de Github debe llamar al finalizar. Acepta objeto JSON vacío si no hay inputs adicionales).

Casos de uso: Disparar un deploy desde n8n y esperar confirmación antes de notificar al equipo o continuar con siguientes pasos, ejecutar tests de integración en Github Actions y procesar resultados en n8n solo cuando terminen, orquestar pipelines complejos donde n8n coordina múltiples workflows de Github y reacciona según cada resultado.

Cuándo usarlo: Cuando necesitas ejecución síncrona entre n8n y Github Actions, esperando el resultado antes de tomar decisiones en tu workflow n8n (notificaciones, rollbacks, siguientes pasos condicionales).

Dispara un workflow de Github Actions mediante un evento workflow_dispatch, permitiendo ejecutar workflows manualmente o desde automatizaciones externas. A diferencia de "Dispatch and Wait for Completion", esta acción no espera a que el workflow termine: lanza la ejecución y el workflow n8n continúa inmediatamente. Útil para iniciar pipelines asíncronos (deploys, tests, generación de reportes) sin bloquear n8n.

Parámetros clave: Repository Owner (Selección del propietario del repo desde lista. Requerido). Repository Name (Selección del repositorio desde lista. Requerido). Workflow (Selección del workflow a disparar desde lista. Requerido). Ref (Dropdown para seleccionar rama, tag o commit SHA de ejecución. Requerido para especificar la referencia Git). Inputs (Campo JSON para pasar inputs personalizados definidos en el workflow_dispatch del workflow. Acepta si no hay inputs. Opcional pero útil para parametrizar la ejecución).

Casos de uso: Disparar deploys automáticos cuando se cierra un issue etiquetado como "ready-to-deploy", ejecutar workflows de generación de reportes diarios desde n8n a horarios específicos, lanzar tests de integración cada vez que se crea un nuevo PR (combinando con otros nodos n8n).

Cuándo usarlo: Para iniciar workflows de forma asíncrona, sin necesidad de esperar resultados en n8n. Perfecto para fire-and-forget scenarios donde el workflow de Github opera independientemente.

Deshabilita un workflow de Github Actions, impidiendo que se ejecute automáticamente o manualmente hasta que se reactive. Útil para pausar pipelines temporalmente durante mantenimientos, incidentes o cuando necesitas detener deploys automáticos sin eliminar la configuración del workflow.

Parámetros clave: Repository Owner (Selección del propietario del repo desde lista. Requerido). Repository Name (Selección del repositorio desde lista. Requerido). Workflow (Selección del workflow a deshabilitar desde lista de workflows en el repo. Requerido para identificar el workflow objetivo).

Casos de uso: Pausar workflows de deploy durante ventanas de mantenimiento planificadas, deshabilitar temporalmente pipelines problemáticos mientras se debuggea un issue, implementar circuit breakers: deshabilitar workflows automáticamente tras X fallos consecutivos.

Cuándo usarlo: En workflows de control que gestionan ventanas de mantenimiento, o para implementar lógica de circuit breaker que deshabilita pipelines ante condiciones anómalas (múltiples fallos, alertas críticas).

Envía una invitación a un usuario para unirse a tu organización Github, especificando su email. El usuario recibirá un email de Github con el link de invitación. Esta acción automatiza la incorporación de colaboradores sin intervención manual, ideal para onboarding automatizado de equipos o gestión de accesos.

Parámetros clave: Organization (Campo de texto donde ingresas el nombre de tu organización Github. Requerido para especificar a qué organización invitar al usuario). Email (Campo de texto donde ingresas el email del usuario a invitar formato name@email.com. Requerido para identificar al usuario destinatario de la invitación).

Casos de uso: Automatizar onboarding: cuando un nuevo empleado se registra en tu HRIS, n8n invita automáticamente su email a la org Github, invitar colaboradores externos tras aprobar un formulario de solicitud de acceso, sincronizar membresías entre múltiples plataformas (ej: añadir a Github cuando se añade a Slack, Notion, etc.).

Cuándo usarlo: En workflows de onboarding/offboarding de equipos, o para sincronizar accesos entre diferentes herramientas de tu stack cuando incorporas nuevos colaboradores.

Recupera la lista de issues asignados o creados por el usuario autenticado en Github. A diferencia de obtener issues de un repo específico, esta acción consulta todos los repos accesibles por el usuario, devolviendo issues según filtros como estado (abiertos/cerrados), labels, milestones, etc. Útil para dashboards personales o reportes de actividad del usuario.

Parámetros clave: Return All (Toggle switch para devolver todos los issues sin límite. Si está desactivado, aplica el límite especificado. Opcional). Limit (Campo numérico que establece el máximo de issues a recuperar. Mostrado aquí en 50. Requerido cuando "Return All" está desactivado). Filters (Sección expandible para añadir filtros adicionales estado, labels, milestones, fechas, etc. Opcional pero útil para refinar resultados según criterios específicos).

Casos de uso: Generar reportes diarios de issues asignados al usuario autenticado y enviarlos por email/Slack, crear dashboards personales mostrando issues pendientes del usuario en múltiples repos, monitorear carga de trabajo del usuario y alertar si excede ciertos umbrales.

Cuándo usarlo: Para workflows centrados en la actividad del usuario autenticado, dashboards personales o reportes de productividad individual.

Lista los repositorios accesibles por un usuario específico en Github. Devuelve repos públicos y privados (según permisos) del usuario indicado, con detalles como nombre, descripción, lenguajes, estrellas, forks, etc. Útil para auditar repositorios de usuarios, generar inventarios o sincronizar repos con sistemas externos.

Parámetros clave: Repository Owner (Campo con selector "From list" para elegir el usuario/organización cuyo repositorio listar. Requerido para determinar de quién obtener los repos). Return All (Toggle switch para devolver todos los repos sin límite. Si está desactivado, aplica el límite. Opcional). Limit (Campo numérico que establece cuántos repos recuperar máximo. Mostrado aquí en 50. Requerido cuando "Return All" está off).

Casos de uso: Generar inventarios automáticos de todos los repos de tu organización con metadatos (lenguajes, actividad, tamaño), auditar repos públicos vs privados para compliance o seguridad, sincronizar lista de repos con herramientas de gestión de proyectos o documentación.

Cuándo usarlo: En workflows de auditoría, inventario o sincronización de repositorios con sistemas externos (CMDBs, wikis, herramientas de gestión).

Actualiza el cuerpo (comentario) de una review existente en un Pull Request. Permite modificar el texto de feedback de una review ya creada, útil para corregir errores, añadir información adicional o actualizar el estado de la revisión sin crear una nueva review desde cero.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo desde lista. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). PR Number (Campo numérico para especificar el número del Pull Request. Mostrado aquí con valor 0 placeholder, debe cambiarse al PR real. Requerido). Review ID (Campo de texto donde ingresas el ID de la review a actualizar. Este ID se obtiene al crear o listar reviews. Requerido para identificar la review objetivo). Body (Campo de texto multilínea donde ingresas el nuevo contenido del comentario de la review. Requerido para actualizar el texto de feedback).

Casos de uso: Corregir automáticamente typos o errores en reviews tras procesamiento NLP, añadir información complementaria a reviews después de ejecutar checks automáticos adicionales, actualizar el feedback de una review según cambios posteriores en el PR.

Cuándo usarlo: Cuando necesitas modificar reviews existentes dinámicamente, especialmente en workflows que procesan PRs automáticamente y ajustan feedback según resultados de análisis posteriores.

Recupera múltiples reviews de un Pull Request específico, devolviendo hasta un límite configurable o todas las reviews disponibles. Incluye detalles de cada review: autor, estado (aprobado, cambios solicitados, comentario), cuerpo del comentario, fecha, etc. Útil para analizar feedback de PRs, generar reportes de revisiones o automatizar acciones según reviews.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido). PR Number (Campo de texto para ingresar el número del PR. Mostrado en 0 placeholder. Requerido para especificar el Pull Request). Return All (Toggle switch para devolver todas las reviews sin límite. Si está off, aplica el límite. Opcional). Limit (Campo numérico que establece cuántas reviews recuperar máximo. Configurado aquí en 50. Requerido cuando "Return All" está desactivado).

Casos de uso: Generar reportes automáticos de tiempo de revisión promedio por PR en tu equipo, analizar patrones de reviews (quién revisa más, tipos de feedback) para métricas de equipo, automatizar merges cuando un PR tiene X aprobaciones de reviewers específicos.

Cuándo usarlo: Para workflows que analizan o reaccionan al estado de reviews en PRs, como auto-merges condicionales, notificaciones a autores según feedback, o generación de reportes de code review.

Obtiene los detalles de una review específica en un Pull Request, identificada por su Review ID. Devuelve información completa: autor, estado (approved, changes_requested, commented), cuerpo del comentario, fecha de creación, etc. Útil cuando necesitas información detallada sobre una review concreta para procesarla o tomar decisiones basadas en ella.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). PR Number (Campo numérico para especificar el número del Pull Request. Mostrado en 0 placeholder. Requerido). Review ID (Campo de texto donde ingresas el ID único de la review a recuperar. Requerido para identificar la review específica).

Casos de uso: Verificar el estado de una review antes de tomar acciones (notificar, mergear, solicitar cambios), obtener detalles de reviews para logging, auditoría o análisis de calidad de code reviews, procesar feedback de reviewers específicos para workflows condicionales (ej: solo mergear si reviewer senior aprobó).

Cuándo usarlo: Cuando necesitas información detallada de una review específica para tomar decisiones en tu workflow, como validar aprobaciones antes de mergear o procesar comentarios de reviewers críticos.

Crea una nueva review en un Pull Request, especificando el tipo de review (aprobar, solicitar cambios, comentar) y opcionalmente el cuerpo del comentario. Esta acción automatiza el proceso de revisión de código, permitiendo workflows donde reviews se generan automáticamente según análisis previos (linters, tests, security scans).

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). PR Number (Campo numérico para especificar el número del PR a revisar. Mostrado en 0 placeholder. Requerido). Event (Dropdown para seleccionar el tipo de review. Opciones típicas: "Approve" aprobar cambios, "Request Changes" solicitar modificaciones, "Comment" comentar sin aprobar/rechazar. Mostrado aquí en "Approve". Requerido para definir la acción de la review). Additional Fields (Sección expandible para añadir propiedades opcionales como body texto del comentario de la review, comments comentarios inline en líneas específicas, etc. Opcional).

Casos de uso: Aprobar automáticamente PRs que pasan todos los checks de CI/CD y no tienen cambios en archivos críticos, solicitar cambios automáticamente si linters o security scanners detectan issues en el PR, crear reviews con comentarios automáticos generados por análisis de código (complejidad, cobertura, vulnerabilidades).

Cuándo usarlo: En workflows de automatización de code reviews donde herramientas externas (CI/CD, linters, security tools) generan reviews automáticas basadas en análisis del código del PR.

Lista las fuentes de tráfico (referrers) que han dirigido visitas a tu repositorio Github. Devuelve datos de analytics sobre de dónde vienen los visitantes (otros repos, sitios web, redes sociales, etc.) y cuántas visitas generó cada fuente. Útil para analizar la visibilidad de tu repo, identificar canales de promoción efectivos o generar reportes de marketing para proyectos open source.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido para especificar a quién pertenece el repositorio). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido para determinar de qué repo obtener los referrers).

Casos de uso: Generar reportes semanales de fuentes de tráfico para proyectos open source y compartirlos con el equipo, identificar sitios web o blogs que enlazan frecuentemente tu repo para agradecer o colaborar, analizar impacto de campañas de marketing midiendo picos de tráfico desde fuentes específicas.

Cuándo usarlo: En workflows de analytics y marketing para proyectos Github, especialmente útil para open source o repos públicos donde el tráfico importa para visibilidad y adopción.

Lista las rutas (paths) más visitadas dentro de tu repositorio Github, mostrando qué archivos o directorios reciben más tráfico. Incluye estadísticas de vistas y visitantes únicos por path. Útil para identificar contenido popular, documentación más consultada o archivos de código con mayor interés, ayudando a priorizar mantenimiento o mejoras.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido).

Casos de uso: Identificar qué documentación (README, guías) es más consultada para mejorarla o ampliarla, detectar archivos de código con alto interés para refactorizar, documentar mejor o destacar en comunicaciones, generar reportes de engagement sobre tu proyecto open source (qué partes atraen más atención).

Cuándo usarlo: Para workflows de analytics de contenido en Github, priorizando mantenimiento de documentación o código según popularidad real medida por vistas.

Recupera la lista de Pull Requests de un repositorio específico, con opciones para filtrar por estado (abiertos, cerrados, todos), labels, milestones, autor, etc. Devuelve información detallada de cada PR: título, descripción, autor, reviewers, estado de checks, etc. Ideal para generar reportes de PRs pendientes, analizar velocidad de revisión o automatizar acciones según estado de PRs.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido). Return All (Toggle switch para devolver todos los PRs sin límite. Si está off, aplica el límite. Opcional). Limit (Campo numérico que establece cuántos PRs recuperar máximo. Configurado aquí en 50. Requerido cuando "Return All" está desactivado). Filters (Sección expandible para añadir filtros estado, labels, autor, fechas, etc. Actualmente muestra "No properties" pero permite refinar los PRs devueltos. Opcional).

Casos de uso: Generar reportes diarios de PRs abiertos pendientes de revisión y enviarlos al equipo por Slack, monitorear tiempo de vida de PRs y alertar si exceden umbrales (ej: más de 7 días abiertos), automatizar merges de PRs que cumplen criterios (aprobados, sin conflictos, checks pasados).

Cuándo usarlo: Para workflows de gestión de PRs, reportes de actividad del repo, o automatizaciones que reaccionan al estado de Pull Requests (notificaciones, auto-merges, análisis de velocidad de equipo).

Obtiene el perfil público del propietario (usuario u organización) de un repositorio Github. Devuelve información como nombre, bio, localización, URL del blog, cantidad de repos públicos, seguidores, etc. Útil para enriquecer datos sobre contributors, generar perfiles de colaboradores o sincronizar información de usuarios Github con sistemas CRM.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo cuyo perfil obtener. Requerido para identificar el usuario/organización). Repository Name (Dropdown "From list" para seleccionar el repositorio aunque esta acción consulta el perfil del owner, no el repo en sí. Requerido por estructura de la API).

Casos de uso: Enriquecer perfiles de contributors en bases de datos internas con info de Github (bio, localización, links), generar listados automáticos de colaboradores de proyectos open source con sus perfiles completos, sincronizar datos de usuarios Github con CRMs o herramientas de gestión de comunidades.

Cuándo usarlo: En workflows de gestión de comunidades, onboarding de contributors o sincronización de datos de usuarios entre Github y sistemas externos.

Recupera información sobre la licencia del repositorio especificado, si existe. Devuelve detalles como nombre de la licencia (MIT, Apache 2.0, GPL, etc.), clave, URL y contenido del archivo LICENSE. Útil para auditar licencias en tu organización, verificar compliance o generar inventarios de licencias de proyectos.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio cuya licencia consultar. Requerido para identificar el repo objetivo).

Casos de uso: Auditar licencias de todos los repos de tu organización para asegurar compliance con políticas corporativas, generar reportes automáticos de licencias open source usadas en dependencias o proyectos internos, verificar existencia de LICENSE antes de publicar proyectos internos como open source.

Cuándo usarlo: En workflows de compliance, auditoría legal o gestión de políticas de licencias en organizaciones con múltiples repositorios.

Recupera la lista de issues de un repositorio específico, con opciones para filtrar por estado (abiertos, cerrados, todos), labels, milestones, asignados, autor, fechas, etc. Devuelve información completa de cada issue: título, descripción, autor, asignados, labels, comentarios, etc. Fundamental para automatizar gestión de issues, generar reportes de backlog o sincronizar issues con herramientas de gestión de proyectos como ClickUp.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido). Return All (Toggle switch para devolver todos los issues sin límite. Si está off, aplica el límite. Opcional). Limit (Campo numérico que establece cuántos issues recuperar máximo. Configurado aquí en 50. Requerido cuando "Return All" está desactivado). Filters (Sección expandible para añadir filtros estado, labels, asignados, milestones, fechas. Actualmente muestra "No specific filters" pero permite refinar resultados. Opcional).

Casos de uso: Sincronizar issues de Github con gestores de proyectos (Jira, Linear, Trello) para mantener backlog unificado, generar reportes semanales de issues abiertos por prioridad/label y enviarlos al equipo, automatizar asignación de issues según keywords en título/descripción o labels aplicados.

Cuándo usarlo: Para workflows de sincronización de issues, reportes de backlog, o automatizaciones que procesan y clasifican issues según criterios (auto-asignación, notificaciones, escalaciones).

Obtiene información detallada de un repositorio específico: nombre, descripción, visibilidad (público/privado), lenguajes principales, cantidad de estrellas, forks, watchers, issues abiertos, fecha de creación, última actualización, topics, etc. Esencial para auditar repos, generar inventarios completos o enriquecer datos de repositorios en sistemas externos.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido para identificar a quién pertenece). Repository Name (Dropdown "From list" para seleccionar el repositorio específico. Requerido para determinar qué repo consultar).

Casos de uso: Generar inventarios automáticos de repos con metadatos completos (lenguajes, tamaños, actividad), auditar configuraciones de repos (visibilidad, protecciones de ramas, webhooks) para compliance, enriquecer wikis o documentación interna con datos dinámicos de repos (estrellas, forks, última actividad).

Cuándo usarlo: En workflows de inventario, auditoría o documentación automática de repositorios en tu organización Github.

Actualiza los detalles de una release existente en Github: nombre, descripción, tag, prerelease status, draft status, etc. Permite modificar releases publicadas para corregir información, añadir detalles o cambiar configuraciones sin crear una nueva release.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Release ID (Campo de texto donde ingresas el ID único de la release a actualizar. Requerido para identificar la release objetivo). Additional Fields (Sección expandible para definir qué propiedades actualizar name, body, draft, prerelease, tag_name, etc. Opcional pero necesario para realizar cambios concretos).

Casos de uso: Corregir automáticamente typos o errores en descripciones de releases tras publicación, marcar releases como "latest" o actualizar changelog añadiendo información de hotfixes, cambiar status de prerelease a release oficial tras validaciones exitosas en producción.

Cuándo usarlo: En workflows de gestión de releases donde se requiere modificar releases existentes dinámicamente según eventos posteriores (validaciones, hotfixes, correcciones).

Recupera múltiples releases de un repositorio, devolviendo hasta un límite configurable o todas las releases disponibles. Incluye información de cada release: tag, nombre, descripción, fecha de publicación, assets, draft/prerelease status, etc. Útil para listar historial de releases, generar changelogs automáticos o analizar frecuencia de publicaciones.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown "From list" para seleccionar el repositorio. Requerido). Return All (Toggle switch para devolver todas las releases sin límite. Si está off, aplica el límite. Opcional). Limit (Campo numérico que establece cuántas releases recuperar máximo. Configurado aquí en 50. Requerido cuando "Return All" está desactivado).

Casos de uso: Generar páginas de changelog automáticas listando todas las releases con sus descripciones, analizar frecuencia de releases para métricas de delivery (cuántas releases por mes/trimestre), notificar automáticamente a usuarios sobre nuevas releases comparando con última notificación enviada.

Cuándo usarlo: Para workflows de generación de changelogs, reportes de delivery o notificaciones automáticas de nuevas versiones a stakeholders.

Obtiene los detalles completos de una release específica identificada por su Release ID. Devuelve información detallada: tag, nombre, descripción, autor, fecha de publicación, assets descargables, draft/prerelease status, etc. Útil cuando necesitas información precisa sobre una release concreta para procesarla o tomar decisiones basadas en ella.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Release ID (Campo de texto donde ingresas el ID único de la release a consultar. Requerido para identificar la release específica).

Casos de uso: Obtener URL de assets de una release para distribuirlos automáticamente (enviar links de descarga por email), verificar status de release (draft/prerelease) antes de notificar públicamente sobre ella, procesar metadata de releases para generar anuncios personalizados según contenido del changelog.

Cuándo usarlo: Cuando necesitas información detallada de una release específica para workflows de distribución de assets, notificaciones personalizadas o validaciones de release status.

Elimina una release existente de Github identificada por su Release ID. Borra la release completa incluyendo sus assets, pero no elimina el tag Git asociado (el tag permanece en el repositorio). Útil para limpiar releases erróneas, drafts antiguos o prereleases obsoletas.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Release ID (Campo de texto donde ingresas el ID único de la release a eliminar. Requerido para identificar la release objetivo).

Casos de uso: Limpiar automáticamente prereleases antiguas tras publicar release oficial, eliminar releases draft creadas por error o durante testing de pipelines de release, implementar políticas de retención: borrar releases más antiguas que X meses.

Cuándo usarlo: En workflows de limpieza de releases, políticas de retención o corrección de errores en procesos de release automatizados.

Crea una nueva release en Github, especificando tag, nombre, descripción (changelog), draft/prerelease status y opcionalmente adjuntando assets. Fundamental para automatizar procesos de release, generando publicaciones automáticas tras deployments exitosos o siguiendo flujos de versionado semántico.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Tag (Campo de texto donde especificas el tag Git para la release ej: v1.2.3. Opcional pero esencial para identificar la versión). Additional Fields (Sección expandible para definir propiedades como name nombre de la release, body descripción/changelog, draft boolean para release draft, prerelease boolean para prerelease, target_commitish rama/commit base, etc. Opcional).

Casos de uso: Crear releases automáticas tras merges a main con changelog generado desde commits o PRs, publicar prereleases automáticas para ramas de staging tras deployments exitosos en entornos de prueba, generar releases con assets compilados automáticamente (binarios, paquetes) adjuntados desde pipelines CI/CD.

Cuándo usarlo: En workflows de CI/CD donde releases se publican automáticamente tras validaciones exitosas, o para implementar flujos de versionado semántico automatizados.

Lista los repositorios de una organización Github, devolviendo repos públicos y privados (según permisos) con metadatos: nombre, descripción, lenguajes, visibilidad, actividad, etc. Útil para auditar repos organizacionales, generar inventarios o sincronizar listados de repos con sistemas de gestión.

Parámetros clave: Repository Owner (Dropdown "From list" para seleccionar la organización cuyo repositorios listar. Requerido para identificar la org). Return All (Toggle switch para devolver todos los repos sin límite. Si está off, aplica el límite. Opcional). Limit (Campo numérico que establece cuántos repos recuperar máximo. Configurado aquí en 50. Requerido cuando "Return All" está desactivado).

Casos de uso: Generar inventarios completos de repos de tu organización para auditorías de seguridad o compliance, sincronizar listados de repos con herramientas de documentación (wikis, portales internos), analizar distribución de lenguajes o tecnologías usadas en repos organizacionales.

Cuándo usarlo: En workflows de inventario organizacional, auditorías de repos o sincronización de datos de Github con sistemas de gestión de proyectos/documentación.

Bloquea un issue de Github, impidiendo que se añadan nuevos comentarios o ediciones. Se debe especificar una razón para el bloqueo (off-topic, too heated, resolved, spam). Útil para cerrar discusiones finalizadas, prevenir spam o moderar issues conflictivos.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Issue Number (Campo de texto para especificar el número del issue a bloquear. Requerido para identificar el issue). Lock Reason (Dropdown para seleccionar la razón del bloqueo. Opciones típicas: "Off-topic", "Too heated", "Resolved", "Spam". Mostrado aquí en "Resolved". Requerido para documentar por qué se bloquea).

Casos de uso: Bloquear automáticamente issues marcados como resueltos tras X días de inactividad, moderar issues automáticamente cuando se detecta spam o lenguaje inapropiado (integración con análisis de texto), cerrar discusiones en issues tras deployments exitosos que resuelven el problema reportado.

Cuándo usarlo: En workflows de moderación de issues, automatización de cierre de discusiones resueltas o prevención de spam en repos públicos.

Obtiene información detallada de un issue específico identificado por su número: título, descripción, autor, asignados, labels, milestone, comentarios, estado (abierto/cerrado), fechas, etc. Fundamental para procesar issues individuales, verificar estados o extraer información para sincronización con herramientas externas.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Issue Number (Campo numérico para especificar el número del issue a consultar. Mostrado en 0 placeholder. Requerido para identificar el issue objetivo).

Casos de uso: Obtener detalles de un issue para sincronizarlo con gestores de proyectos (crear/actualizar tarea en Jira), verificar estado de issue antes de tomar acciones (notificar, cerrar, reasignar), extraer información de issues para procesamiento (análisis de sentimiento, categorización automática).

Cuándo usarlo: Cuando necesitas información detallada de un issue específico para procesarlo, sincronizarlo con sistemas externos o tomar decisiones condicionales basadas en su estado.

Actualiza las propiedades de un issue existente: título, descripción, labels, asignados, milestone, estado (abierto/cerrado), etc. Permite modificar issues sin intervención manual, esencial para automatizar gestión de backlog, reasignaciones o actualizaciones de estado según eventos externos.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Issue Number (Campo numérico para especificar el número del issue a editar. Mostrado en 0 placeholder. Requerido). Edit Fields (Sección expandible para seleccionar qué propiedades actualizar title, body, labels, assignees, milestone, state. Actualmente muestra "No properties" pero permite añadir campos a modificar. Opcional pero necesario para realizar cambios).

Casos de uso: Actualizar automáticamente labels de issues según análisis de contenido (ej: añadir "bug" si descripción contiene keywords), cerrar issues automáticamente tras deployments exitosos que resuelven el problema, reasignar issues según carga de trabajo del equipo o rotación de responsabilidades.

Cuándo usarlo: En workflows de gestión automática de issues donde cambios de estado, reasignaciones o actualizaciones de metadata se disparan por eventos externos (deployments, análisis, cambios en otros sistemas).

Añade un comentario a un issue específico de Github. Permite automatizar respuestas, notificaciones o aportar información adicional a issues sin intervención manual. Fundamental para workflows de soporte automatizado, bots de Github o integración de herramientas externas que comentan en issues.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Issue Number (Campo numérico para especificar el número del issue donde comentar. Mostrado en 0 placeholder. Requerido). Body (Campo de texto multilínea donde ingresas el contenido del comentario. Requerido para proporcionar el texto del comentario).

Casos de uso: Comentar automáticamente en issues cuando se despliega un fix a producción ("Fixed in v1.2.3"), bots que responden a issues con información predefinida o solicitan detalles adicionales, notificar en issues resultados de análisis automáticos (security scans, performance tests).

Cuándo usarlo: Para workflows de automatización de comunicación en issues, bots de soporte o integración de resultados de herramientas externas comentando en issues relevantes.

Crea un nuevo issue en Github especificando título, descripción, labels, asignados, milestone, etc. Fundamental para automatizar creación de issues desde fuentes externas (formularios, tickets de soporte, errores de aplicaciones) o generar issues programáticamente según condiciones.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Title (Campo de texto donde especificas el título del issue. Requerido para identificar el issue). Body (Campo de texto multilínea para la descripción detallada del issue. Opcional pero recomendado para claridad). Labels (Sección para añadir labels al issue. Soporta múltiples labels. Opcional pero útil para categorización). Assignees (Sección para asignar el issue a usuarios específicos. Opcional).

Casos de uso: Crear issues automáticamente desde formularios de reporte de bugs enviados por usuarios, generar issues de seguimiento tras deployments para tracking de cambios en producción, crear issues programáticamente cuando monitores detectan problemas (errores en logs, caídas de servicios).

Cuándo usarlo: En workflows de integración entre Github y fuentes externas (formularios, sistemas de soporte, monitoreo) donde issues se crean automáticamente desde eventos o datos externos.

Lista los archivos y directorios en un path específico de un repositorio Github. Devuelve nombres, tipos (file/dir), tamaños, SHAs y URLs de cada elemento. Útil para explorar contenido de repos programáticamente, verificar existencia de archivos o generar índices de documentación.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). Path (Campo de texto donde especificas el directorio a listar ej: docs/. Requerido para determinar qué carpeta explorar).

Casos de uso: Verificar existencia de archivos de configuración antes de ejecutar operaciones (ej: validar que existe .env.example), generar índices automáticos de documentación listando archivos markdown en carpeta docs/, explorar estructura de repos para auditorías de organización de código o compliance.

Cuándo usarlo: Cuando necesitas explorar contenido de repos programáticamente para validaciones, generación de índices o análisis de estructura de proyectos.

Descarga el contenido de un archivo específico de un repositorio Github. Puede devolver el contenido como texto o como propiedad binaria (útil para archivos no textuales). Esencial para procesar archivos de repos, leer configuraciones o descargar assets.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). File Path (Campo de texto donde especificas la ruta exacta del archivo ej: docs/README.md. Requerido para identificar el archivo). As Binary Property (Toggle switch para devolver contenido como binario en lugar de texto. Activado en el screenshot, útil para archivos no textuales imágenes, PDFs, etc). Put Output File in Field (Campo de texto para nombrar el campo donde se colocará el contenido binario. Mostrado aquí como "data". Define dónde acceder al contenido en el output).

Casos de uso: Leer archivos de configuración de repos para procesarlos en workflows (parsear YAML, JSON), descargar READMEs para generar documentación centralizada agregando contenido de múltiples repos, obtener assets de repos (logos, imágenes) para usarlos en notificaciones, dashboards o reportes.

Cuándo usarlo: Cuando necesitas leer o descargar contenido específico de archivos en repos para procesarlos, analizarlos o usarlos en pasos posteriores del workflow.

Modifica el contenido de un archivo existente en un repositorio Github. Requiere especificar el nuevo contenido y un mensaje de commit. Permite editar archivos programáticamente sin tocar Git manualmente, útil para actualizar documentación, configuraciones o código automáticamente.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). File Path (Campo de texto especificando la ruta del archivo a editar ej: docs/README.md. Requerido). Binary File (Toggle switch para indicar si el archivo es binario. Desactivado aquí, indica archivo de texto. Opcional). File Content (Campo de texto multilínea donde ingresas el nuevo contenido del archivo. Opcional pero necesario para cambiar el contenido). Commit Message (Campo de texto para el mensaje de commit que describe el cambio. Opcional pero recomendado para claridad en historial Git). Additional Parameters (Sección expandible para opciones adicionales branch, author, etc. Opcional).

Casos de uso: Actualizar automáticamente README.md con badges de build status, cobertura o versión tras cada release, modificar archivos de configuración en repos tras cambios en sistemas externos (actualizar versiones de dependencias), editar documentación programáticamente agregando información generada automáticamente (changelogs, tablas de API).

Cuándo usarlo: En workflows donde archivos de repos deben actualizarse automáticamente según eventos externos (releases, cambios de configuración, generación de documentación).

Elimina un archivo de un repositorio Github, creando un commit con el mensaje especificado. Útil para limpiar archivos obsoletos, remover documentación antigua o automatizar gestión de contenido en repos.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). File Path (Campo de texto especificando la ruta exacta del archivo a eliminar ej: docs/README.md. Requerido para identificar el archivo objetivo). Commit Message (Campo de texto para el mensaje de commit que documenta la eliminación. Opcional pero recomendado para claridad). Additional Parameters (Sección expandible para opciones adicionales. Opcional).

Casos de uso: Limpiar automáticamente documentación obsoleta cuando se publican nuevas versiones, eliminar archivos temporales o de testing tras pipelines CI/CD, implementar políticas de retención: borrar archivos más antiguos que X meses automáticamente.

Cuándo usarlo: En workflows de limpieza automática de repos, políticas de retención de archivos o gestión de contenido donde archivos se eliminan según condiciones (antigüedad, obsolescencia).

Crea un nuevo archivo en un repositorio Github especificando su ruta, contenido y mensaje de commit. Permite añadir archivos programáticamente sin Git manual, útil para generar documentación automática, crear configuraciones o añadir assets.

Parámetros clave: Repository Owner (Dropdown para seleccionar el propietario del repo. Requerido). Repository Name (Dropdown para seleccionar el repositorio. Requerido). File Path (Campo de texto especificando ruta y nombre del archivo a crear ej: docs/README.md. Requerido para definir ubicación). Binary File (Toggle switch para indicar si el archivo es binario. Desactivado aquí, indica archivo de texto. Opcional). File Content (Campo de texto multilínea donde ingresas el contenido inicial del archivo. Requerido para proporcionar contenido). Commit Message (Campo de texto para el mensaje de commit que documenta la creación. Requerido para claridad en historial Git). Additional Parameters (Sección expandible para opciones adicionales. Opcional).

Casos de uso: Generar automáticamente archivos de changelog tras cada release listando commits o PRs, crear archivos de documentación dinámicamente agregando información de APIs, configuraciones o ejemplos, añadir assets a repos (imágenes, diagramas) generados automáticamente por herramientas externas.

Cuándo usarlo: En workflows de generación automática de documentación, assets o configuraciones donde archivos se crean programáticamente según datos o eventos externos. Si necesitas ayuda avanzada para implementar estos workflows, consulta nuestro curso n8n.