Integración GitLab MakeAutomatiza GitLab con Make.

Fusiona los cambios que trae una merge request, el mismo clic que daría quien revisa, hecho por el escenario.

Corta un build de un proyecto antes de que llegue al final.

Una llamada y se paran todos los builds del pipeline. Más amplio que cancelar un job suelto y más rápido que ir uno por uno.

Anula la fusión que GitLab iba a hacer en cuanto el pipeline se pusiera en verde. La merge request vuelve a manos humanas.

Copia un commit a otra rama sin arrastrar el historial detrás.

Escribe un archivo nuevo en el repositorio, commit incluido. Tu escenario produce contenido, no solo lo lee.

Levanta un grupo de GitLab, el contenedor que reúne proyectos y a la gente autorizada en ellos.

Añade una etiqueta al repositorio con el nombre y el color que le des. Las etiquetas son como GitLab ordena incidencias y merge requests.

Abre una merge request desde el escenario, con rama de origen y rama de destino incluidas.

Publica un comentario en una merge request. La forma más simple de que un escenario hable donde ya está la conversación.

Levanta un hito de proyecto, el cajón que usa GitLab para agrupar incidencias alrededor de una fecha o una versión.

Deja un ticket en el proyecto que elijas, con el título y la descripción que arma tu escenario. Muchos primeros escenarios terminan justo aquí.

Suelta un comentario debajo de una incidencia existente. El hilo se queda en su sitio y gana lo que el escenario averiguó.

Lanza un pipeline en un proyecto, la misma ejecución que arrancarías desde la página de CI.

Engancha notas de versión a un tag de git que ya existe. El tag pasa a ser una página legible y no un nombre en una lista.

Corta una rama nueva en el proyecto a partir de la referencia que le indiques.

Comenta un snippet, ese trozo de código suelto que GitLab guarda fuera del repositorio.

Coloca un tag sobre la referencia que le pases, y así es como una versión recibe su nombre.

Pone una incidencia en la lista de todos de la cuenta que hay detrás de tu conexión. El recordatorio propio de GitLab, creado por el escenario.

El mismo recordatorio, apuntado a una merge request en lugar de a una incidencia. La revisión aparece en tus todos de GitLab.

Agrega una variable de build al proyecto, el valor que los pipelines leen mientras se ejecutan.

Elimina un archivo existente del repositorio y, como en la creación, pasa por un commit.

Saca una etiqueta del proyecto para siempre.

Una merge request se borra en modo suave desde aquí, y solo pueden hacerlo administradores y propietarios del proyecto.

Retira un hito de proyecto cuando su sprint o su versión ya quedaron atrás.

Borra una incidencia en vez de cerrarla. Cerrar la esconde, borrar la quita.

Quita una rama del proyecto, de una en una.

Saca un tag del repositorio.

Jubila una variable de build de la configuración del proyecto.

Borrar un job elimina sus artefactos y su traza. El registro de la ejecución se va y el almacenamiento vuelve.

Ejecuta una consulta GraphQL autorizada contra GitLab con la conexión ya hecha. La salida de emergencia para los datos que los demás módulos no exponen.

Vuelve un commit, localizado por un hash, por el nombre de una rama o por el de un tag.

Va a buscar un despliegue concreto de un proyecto para que el escenario sepa qué salió y adónde.

Lee un archivo del repositorio y te devuelve su información, nombre, tamaño y contenido incluidos.

Recupera un build de un proyecto con su estado y sus detalles.

Responde con el detalle de una etiqueta. Módulo pequeño, útil cuando un escenario tiene que decidir a partir de una etiqueta y no a ciegas.

Enseña una merge request entera: título, estado, ramas y lo demás.

Trae de vuelta un único comentario de una merge request, por su identificador.

Entrega un hito de proyecto con sus fechas y su estado.

Lee un ticket del proyecto, que es como un escenario obtiene los detalles de una incidencia que no creó él.

Trae un comentario concreto de una incidencia, con su texto y su autor, listo para el módulo siguiente.

Consulta el estado de un pipeline del proyecto para que el escenario sepa qué hacer con él.

Localiza un proyecto y devuelve sus datos. Lo señalas por nombre, por identificador o por espacio de nombres, según lo que ya tenga el escenario.

Devuelve el contenido de un archivo tal como lo guarda el repositorio, sin nada alrededor.

Pregunta a GitLab por una rama del proyecto y trae sus datos al escenario.

Un comentario dejado bajo un snippet, recogido tal cual y puesto en el escenario.

Busca un tag del repositorio por su nombre y devuelve lo que GitLab sabe de él.

Convierte al usuario que pasó un módulo anterior en datos legibles, nombre incluido.

Una variable de build del proyecto, leída sin entrar en la configuración.

Muestra qué cuenta de GitLab hay detrás de la conexión, sin tocar nada dentro de un proyecto.

Pide a GitLab que conserve los artefactos de un job en vez de dejar que caduquen y desaparezcan.

La salida de emergencia. Este módulo llama a cualquier punto de la API de GitLab, la vía por la que dos programas se hablan, con la conexión que ya creaste.

Marca como hecha una tarea pendiente de la cuenta conectada, igual que un clic en GitLab.

Arranca un job que está esperando a que alguien le dé al play y deja que el pipeline siga.

Escribe un comentario directamente sobre un commit, donde lo verá quien repase el historial.

Relanza los jobs que fallaron dentro de un pipeline y deja en paz a los que pasaron.

Cambia una etiqueta que el proyecto ya tiene, su nombre o su color, desde el escenario y no a mano.

Edita una solicitud de fusión abierta: el título, la rama de destino, y cerrarla también cuenta como edición.

Reescribe un comentario ya publicado en una solicitud de fusión, para dejar un solo mensaje en vez de un montón.

Mantiene un hito al día cuando la planificación cambia en otra herramienta.

Actualiza una incidencia que ya existe, y es también el módulo que la cierra.

Sustituye el texto de un comentario que ya está en una incidencia.

Completa después las notas de una versión, para que un anuncio no se quede con el primer borrador.

Corrige en su sitio una nota dejada bajo un snippet, en lugar de contestarla con otra.

Sobrescribe una variable de build del proyecto con el valor que lleva el escenario.

Abre un commit y trae al escenario el cambio en sí, no solo una referencia.

Reúne los commits que lleva dentro una solicitud de fusión, cada uno por separado, que es lo que permite escribir una línea por commit.

La lista de contribuyentes de un proyecto, nombre a nombre.

Recoge los comentarios que hay bajo un commit y los pasa uno detrás de otro.

Enumera los despliegues de un proyecto, para que el registro viva en otro sitio que no sea la memoria de quien pulsó el botón.

Todos los comentarios de una incidencia, la conversación entera y no un mensaje suelto.

Se adelanta a la fusión y dice qué incidencias se cerrarían si esa solicitud llegara a fusionarse.

Recorre los jobs de un proyecto y los manda al escenario.

Comprueba qué etiquetas existen en un proyecto, que es como el escenario sabe cuáles puede poner.

Mide el tamaño de una solicitud de fusión listando lo que cambia, sin que nadie la abra.

Junta los comentarios de una solicitud de fusión y deja que el escenario haga algo con la discusión.

Responde desde la incidencia a una pregunta sencilla: ¿hay ya una solicitud de fusión en camino de cerrarla?

Agrupa las incidencias colgadas de un hito para que su estado se lea fuera de GitLab.

Repasa los hitos de un proyecto con lo que GitLab sabe de cada uno.

Saca la lista de proyectos de la cuenta conectada, buen punto de partida para un escenario que debe trabajar sobre todos.

List Project Issues abre el proyecto y va soltando sus incidencias en el escenario, una por bundle; un bundle es cada elemento que viaja de un módulo al siguiente.

La lista de contribuidores de un proyecto llega al escenario con este módulo, una persona por bundle, lista para un informe.

Las etiquetas de un proyecto vuelven ordenadas por nombre en orden alfabético inverso, una etiqueta por bundle.

List Repository Tree recorre un proyecto y devuelve sus archivos y carpetas, una entrada por bundle, sin clonar nada.

Las notas de un snippet son los comentarios que la gente deja sobre ese trozo de código, y el módulo los recoge todos de una vez.

List Todos devuelve los todos de la cuenta con la que hiciste la conexión y, cuando no le pones filtro, los que siguen pendientes.

Con List Variables el escenario recibe las variables de build de un proyecto y puede compararlas sin que nadie entre a mirarlas.

Search Groups devuelve la lista de grupos, uno por bundle, que es por donde empieza un escenario antes de bajar a los proyectos.

Las incidencias que abrió la cuenta conectada vuelven todas aquí, sin importar en qué proyecto estén.

Search Merge Requests barre un proyecto entero y devuelve sus merge requests, una por bundle.

El historial de pipelines de un proyecto entra en el escenario con este módulo, una ejecución por bundle.

Search Projects te trae los proyectos en los que la cuenta conectada es miembro, uno por bundle.

Saber qué ramas hay abiertas es el paso previo a cualquier limpieza, y este módulo las devuelve una por bundle.

Cada commit de un proyecto llega por separado al escenario con Search Repository Commits, listo para el módulo que venga detrás.

Cuando el escenario necesita poner nombre a una persona, Search Users localiza su cuenta; sin criterio de búsqueda, devuelve la lista completa.