Integración GitHub n8nAutomatiza GitHub con n8n.

Hace commit de un archivo nuevo en el repositorio. El contenido sale de un texto que escribes o de un campo binario que ha producido un nodo anterior, así que un PDF generado recorre el mismo camino que una página en Markdown.

• File Path: la ruta completa dentro del repositorio, del tipo docs/README.md, no solo el nombre del archivo.
• Binary File: es el desvío. Desmarcado, n8n coge File Content; marcado, coge el archivo que está en Input Binary Field.
• Commit Message: la línea que aparece en el historial del repositorio, así que mejor que diga qué flujo ha escrito.

Quita un archivo del repositorio y registra la eliminación como un commit más, igual que cualquier otro cambio.

• File Path: la ruta completa del archivo que hay que borrar; cuando viene de un nodo anterior, una expresión como {{ $json.filePath }} evita escribirla a mano.
• Commit Message: obligatorio aquí también, y la única explicación que guardará el historial.

Escribe contenido nuevo encima de un archivo que ya existe y hace commit del resultado. Las dos fuentes son las mismas que al crear, texto o binario, con una diferencia que importa: el archivo tiene que estar ahí.

• File Path: señala el archivo que se modifica, con la ruta completa desde la raíz del repositorio, docs/README.md y no README.md.
• File Content: el texto nuevo, normalmente montado por el nodo anterior.
• Binary File con Input Binary Field: la otra vía, cuando la versión nueva llega en binario.
• Commit Message: obligatorio.

Trae un archivo concreto y se lo pasa al nodo siguiente. Por defecto recibes la respuesta cruda de la API; activa As Binary Property y el archivo llega en binario, listo para adjuntarlo a un correo o subirlo a otro sitio.

• File Path: la ruta completa del archivo que se lee.
• Put Output File in Field: el nombre del campo binario de salida que llevará el archivo.
• Reference, en Additional Parameters: un nombre de commit, de rama o de tag. Vacío, GitHub lee la rama por defecto del repositorio, normalmente master.

Enumera lo que contiene una carpeta, un item por entrada. Así es como un flujo recorre un directorio cuyo contenido no puede conocer de antemano.

• File Path: la carpeta que se lee, indicada con la ruta completa desde la raíz del repositorio; el campo lleva la misma etiqueta que en las demás operaciones sobre archivos.

Abre una incidencia nueva en el repositorio y la devuelve, con el número que pedirán todas las operaciones posteriores sobre ella.

• Title: el único campo obligatorio, y la línea que la gente lee en el listado.
• Body: opcional, y en la práctica donde acaban el mensaje de error, el contenido recibido o el enlace que justifica la incidencia.
• Assignees: una colección de nombres de usuario. La colección Labels añade un Label y un Assignee ya en la creación.

Publica un comentario debajo de una incidencia existente. No se mueve nada más: conserva su estado, sus etiquetas y sus responsables.

• Issue Number: un número, no un título. Cógelo del paso que creó o leyó la incidencia en lugar de teclearlo.
• Body: el texto del comentario, muchas veces un resultado que el flujo acaba de calcular.

Actualiza una incidencia que ya está abierta. Todo lo modificable vive en la colección Edit Fields, y solo añades los campos que de verdad quieres tocar.

• Issue Number: la incidencia que se modifica.
• State: open o closed, junto a State Reason, que acepta completed, not_planned o reopened.
• Labels, Assignees, Title, Body: el resto de la colección, para reorientar o reescribir.

Consulta una incidencia y sus datos, sin tocar nada del repositorio. Es el paso de lectura que se pone delante de una decisión: mirar el estado, mirar las etiquetas y elegir después por dónde sigue el flujo.

• Issue Number: el número de la incidencia que se lee.

Bloquea la conversación de una incidencia, lo que impide que el hilo siga acumulando comentarios.

• Issue Number: la incidencia que se bloquea.
• Lock Reason: off-topic, too heated, resolved o spam. El motivo acompaña al bloqueo, así que no hace falta escribir un comentario para explicarlo.

Una llamada y la organización entera sale en forma de lista: un item por repositorio, así que se puede recorrer en bucle una cuenta que nadie quiere inventariar a mano.

• Return All: marcado, n8n encadena las páginas de la API hasta terminar la organización; desmarcado, para en Limit.
• Limit: el número máximo de repositorios devueltos mientras Return All siga desmarcado.

Devuelve las personas que pertenecen a una organización, un item por miembro. El mismo interruptor de paginación que en los repositorios, apuntando a una pregunta muy distinta: quién tiene acceso.

• Return All: desmarcado, n8n devuelve hasta Limit miembros y se detiene ahí; marcado, recorre la plantilla completa.

Crea una release sobre un tag. Puede salir publicada de inmediato. O quedarse en borrador mientras alguien repasa las notas con calma, que es lo normal cuando hay que redactarlas a mano.

• Tag: el tag de la release, el único campo obligatorio.
• Name y Body, en Additional Fields: el título de la release y sus notas.
• Draft la mantiene sin publicar, Prerelease la marca como no lista para producción.
• Target Commitish: la rama o el SHA del commit desde el que se crea el tag. No se usa si el tag ya existe, y vacío recae en la rama por defecto, normalmente master.

Elimina una release identificada por su ID. No hay nada más que rellenar, lo que la convierte también en la operación que conviene revisar dos veces antes de activar el flujo.

• Release ID: el identificador de la release, ni su tag ni su nombre. Sale de un paso de listado como Get Many.

Busca una release y devuelve sus datos, sin cambiar nada por el camino. Es el paso que le da al flujo el nombre y las notas de una versión cuando lo único que ha recibido es un identificador.

• Release ID: la release que se lee, entregada por un paso Get Many o por la operación que la creó unos nodos antes.

Recupera las releases de un repositorio. Sirve cuando el flujo necesita el historial y no solo la última versión.

• Return All: marcado, n8n recorre todo el historial de releases; desmarcado, para en Limit.
• Limit: cuántas releases vuelven cuando Return All está desmarcado.

Modifica una release que ya existe, sean sus notas, su nombre, su tag o su estado.

• Release ID: la release que se actualiza.
• Draft: puesto en false, la release pasa a publicada. Así termina una publicación en dos tiempos.
• Body, Name, Tag Name, Prerelease y Target Commitish: el resto de los Additional Fields.

Aquí no hay ningún parámetro que rellenar. La operación devuelve los datos que GitHub guarda de un repositorio, lo que la convierte en un primer paso barato: un flujo que va a escribir archivos o a abrir incidencias lee antes el repositorio y se detiene enseguida si la respuesta no es la que esperaba.

Saca las incidencias de un repositorio con los mismos filtros que usarías en el listado de GitHub.

• State: open, closed o all.
• Labels: varias etiquetas a la vez, separadas por coma.
• Updated Since: deja solo las incidencias actualizadas a partir de ese momento.
• Assignee, Creator, Mentioned: acotan por persona.
• Sort y Direction: created, updated o comments, en orden ascendente o descendente.
• Return All: desmarcado, la ejecución para en Limit.

Si GitHub ha detectado una licencia en el repositorio, esta operación devuelve su contenido. No pide ningún parámetro, así que encaja justo detrás de un paso de listado y responde repositorio a repositorio. Que no haya nada detectado significa que no hay nada que leer, y ese silencio ya es información.

Lee el perfil de comunidad de un repositorio: métricas, health score, descripción, licencia y lo demás que GitHub mide ahí. Ningún parámetro que ajustar, de modo que añadirla a un flujo no cuesta prácticamente nada.

Un flujo de revisión que corre a hora fija en lugar de por evento empieza aquí, con las pull requests de un repositorio traídas como items.

• State: open, closed o all.
• Sort: created, updated, popularity por número de comentarios, o long-running, que deja solo las pull requests abiertas desde hace más de un mes y con actividad en el último mes.
• Limit: con techo en 100, el máximo que acepta la API para esta lista.

Esta devuelve las 10 rutas de contenido más vistas de un repositorio en los últimos 14 días. Sin filtro y sin rango de fechas: la ventana es fija, así que una vista más larga solo existe si el flujo guarda cada ejecución en algún sitio.

Misma ventana fija, otra pregunta: los 10 primeros dominios de referencia de un repositorio en los últimos 14 días, o sea de dónde llegan las visitas. Tampoco pide parámetros, y con la misma consecuencia, el historial te lo guardas tú.

La operación publica una revisión sobre una pull request abierta, con un veredicto que un comentario suelto no lleva.

• PR Number: el número de la pull request que se revisa, escrito a mano o tomado de un nodo anterior con una expresión, {{ $json.campo }}.
• Event: el veredicto, approve, requestChanges, comment o pending; con pending la revisión queda sin enviar.
• Body: el texto de la revisión, que GitHub exige cuando el Event es Request Change o Comment.
• Commit ID, dentro de Additional Fields: el SHA del commit revisado si no es el último.

Vuelve una sola revisión, la del identificador que recibe el nodo, dentro de la pull request indicada.

• PR Number: la pull request que contiene esa revisión.
• Review ID: el identificador de la revisión que se lee; guarda el que devuelve Create, porque sin él no hay forma de volver a ella.

Salen todas las revisiones de una misma pull request, un item por revisión.

• PR Number: la pull request cuyo historial de revisiones se recorre.
• Return All: activado, n8n encadena las páginas de la API de GitHub hasta la última revisión; desactivado, se detiene en la cifra de Limit.
• Limit: cuántas revisiones como máximo se traen mientras Return All siga apagado.

Aquí solo cambia el texto de una revisión ya publicada: el nodo expone Body y nada más.

• PR Number: la pull request afectada.
• Review ID: la revisión que se reescribe, el mismo identificador que sirve para leerla.
• Body: el texto nuevo, que sustituye al anterior.

El nodo saca la lista de repositorios del usuario, uno por item. No pide ningún identificador: en pantalla solo está la paginación.

• Return All: activado, el nodo pide página tras página hasta el último repositorio; desactivado, corta antes.
• Limit: cuántos repositorios se traen mientras Return All esté desactivado.

Llegan las issues asignadas al usuario, y la colección Filters recorta el montón antes de que estorbe en los nodos siguientes.

• State: open, closed o all.
• Labels: una o varias etiquetas separadas por comas.
• Updated Since: una fecha y una hora; solo pasan las issues actualizadas a partir de ese momento.
• Sort y Direction: orden por created, updated o comments, ascendente o descendente.
• Mentioned: deja únicamente las issues donde se menciona a una persona concreta.

Basta un correo y el nombre de la organización para que la persona reciba su invitación, sin pasar por la página de miembros.

• Organization: la organización de GitHub que recibe a la persona invitada.
• Email: su dirección de correo, con el formato que el campo muestra como ejemplo, name@email.com.

Un workflow del repositorio queda fuera de servicio y sigue así hasta que Enable lo devuelva. Ojo con la palabra: se trata del workflow del repositorio de GitHub, no del flujo n8n que lo rodea.

• Workflow: el que se apaga, elegido en el campo del mismo nombre.

Una orden de dispatch lanza el trabajo cuando tú lo pides, y n8n devuelve el control enseguida: la ejecución no se queda esperando a que termine.

• Workflow: el que se lanza.
• Ref: la referencia git que usa la ejecución, un nombre de rama o de etiqueta, para disparar el mismo workflow sobre una rama de pruebas o sobre una versión publicada.
• Inputs: un objeto JSON con los parámetros de entrada que el workflow espera.

El arranque es idéntico al de Dispatch, lo que viene después no: la ejecución de n8n se detiene y espera un webhook, es decir una URL que se llama desde fuera, antes de seguir con el nodo siguiente.

• Workflow: el que se dispara.
• Ref: el nombre de la rama o de la etiqueta sobre la que corre.
• Inputs: un objeto JSON que lee el trabajo, útil para pasarle un número de versión o un destino.

Reactivar cuesta una sola llamada: los disparadores propios del workflow vuelven a funcionar desde ese mismo momento, sin tocar nada en el repositorio.

• Workflow: el que se reactiva, seleccionado igual que en Disable.

Leer un workflow concreto devuelve un único item, y es la forma más rápida de comprobar que un identificador apunta donde tú crees.

• Workflow: el que se consulta.

GitHub devuelve el uso registrado del workflow que indicas en el campo. Es la cifra que conviene mirar cuando un repositorio gasta más rápido de lo previsto.

• Workflow: aquel cuyo uso se consulta.

No hay nada que rellenar: la operación devuelve los workflows como items, uno por workflow, listos para recorrer en un bucle. Es el punto de partida cuando los identificadores no se conocen de antemano.