Actualización Automática
GitLab MCP Server puede detectar, descargar y aplicar automáticamente nuevas versiones desde GitHub. Las actualizaciones usan un truco de renombrado — el binario en ejecución se renombra a .old, el nuevo binario se coloca en la ruta original, y en Unix el proceso se re-ejecuta sin interrupciones.
Modos de actualización
Sección titulada «Modos de actualización»La variable AUTO_UPDATE controla cómo se manejan las actualizaciones:
| Valor | Modo | Comportamiento |
|---|---|---|
true (por defecto) | Aplicar automáticamente | Detectar y aplicar actualizaciones automáticamente |
check | Solo notificar | Detectar actualizaciones y registrar disponibilidad, pero no aplicar |
false | Deshabilitado | Omitir todas las verificaciones de actualización |
Alias aceptados: 1/yes para true, 0/no para false. El valor no distingue mayúsculas de minúsculas.
Cómo funciona
Sección titulada «Cómo funciona»sequenceDiagram
participant Server as gitlab-mcp-server
participant GitHub as API de GitHub Releases
participant FS as Sistema de Archivos
Server->>Server: CleanupOldBinary()
Server->>GitHub: GET /repos/:owner/:repo/releases/latest
GitHub-->>Server: Metadatos del release + URLs de assets
alt Actualización disponible
Server->>GitHub: Descargar asset del binario
Server->>FS: Escribir en archivo temporal .tmp
Server->>FS: Renombrar actual → .old
Server->>FS: Renombrar .tmp → ruta actual
alt Unix
Server->>Server: syscall.Exec(self) — re-ejecución sin interrupciones
else Windows
Server->>Server: La actualización toma efecto en el próximo reinicio
end
else Actualizado
Server->>Server: Registrar "el servidor está actualizado"
end
Verificación al inicio (modo stdio)
Sección titulada «Verificación al inicio (modo stdio)»En modo stdio (el predeterminado), la actualización automática se ejecuta como una verificación previa al inicio con un timeout de 15 segundos antes de que el servidor MCP comience a aceptar conexiones:
CleanupOldBinary()elimina cualquier archivo.oldsobrante de una actualización anterior- Verifica si hay una versión más nueva en GitHub
- Si el modo es
truey existe una versión más nueva, descarga y reemplaza el binario - En Linux/macOS: se re-ejecuta vía
syscall.Exec()— mismo PID, mismos pipes stdin/stdout, sin interrupción para el cliente MCP - En Windows: registra que la actualización tomará efecto en el próximo reinicio
La verificación al inicio es no fatal — cualquier error (timeout de red, releases no encontrados) se registra como advertencia y no impide que el servidor arranque.
Verificación periódica (modo http)
Sección titulada «Verificación periódica (modo http)»En modo HTTP, la actualización automática se ejecuta como una verificación periódica en segundo plano:
- Una goroutine verifica actualizaciones cada
AUTO_UPDATE_INTERVAL(por defecto: 1 hora) - En cada ciclo, verifica GitHub para un release más nuevo con un timeout de 30 segundos
- Si el modo es
true, aplica la actualización y registra un aviso de reinicio - La goroutine se detiene cuando el servidor se apaga
Configuración
Sección titulada «Configuración»Variables de entorno (modo stdio)
Sección titulada «Variables de entorno (modo stdio)»| Variable | Por Defecto | Descripción |
|---|---|---|
AUTO_UPDATE | true | Modo de actualización: true, check o false |
AUTO_UPDATE_REPO | jmrplens/gitlab-mcp-server | Slug del repositorio de GitHub (propietario/repo) para assets del release |
AUTO_UPDATE_INTERVAL | 1h | Intervalo de verificación (usado por las verificaciones periódicas del modo HTTP) |
Flags de CLI (modo http)
Sección titulada «Flags de CLI (modo http)»| Flag | Por Defecto | Descripción |
|---|---|---|
--auto-update | true | Modo de actualización: true, check o false |
--auto-update-repo | jmrplens/gitlab-mcp-server | Slug del repositorio de GitHub (propietario/repo) para assets del release |
--auto-update-interval | 1h | Intervalo entre verificaciones periódicas de actualización |
Ejemplos de configuración
Sección titulada «Ejemplos de configuración»Desactivar la actualización automática completamente:
AUTO_UPDATE=falseModo de solo verificación (registrar disponibilidad pero no aplicar):
AUTO_UPDATE=checkUsar un repositorio fork personalizado:
AUTO_UPDATE_REPO=mi-org/mi-fork-gitlab-mcpFlag de apagado para actualizadores externos
Sección titulada «Flag de apagado para actualizadores externos»Herramientas externas (como pe-agnostic-store) pueden terminar todas las instancias en ejecución antes de reemplazar el binario en disco:
gitlab-mcp-server --shutdownEste flag:
- Encuentra todos los procesos
gitlab-mcp-serveren ejecución por nombre - Envía una señal de terminación graceful
- Espera hasta 5 segundos a que los procesos terminen
- Fuerza la terminación de cualquier proceso restante
- Finaliza — no se inicia ningún servidor MCP
No se requieren permisos de administrador o root. Esto funciona en Linux, macOS y Windows.
Reversión
Sección titulada «Reversión»Si una actualización causa problemas:
- El binario anterior se conserva como
gitlab-mcp-server.old(o.exe.olden Windows) junto al binario actual - Para revertir, detén el servidor y renombra el archivo
.oldde vuelta al nombre original - El archivo
.oldse limpia automáticamente en el próximo inicio exitoso
Soporte de repositorio personalizado
Sección titulada «Soporte de repositorio personalizado»Puedes apuntar la actualización automática a cualquier repositorio de GitHub que siga el formato de release esperado:
- Establece
AUTO_UPDATE_REPO=propietario/repoa tu repositorio - Crea releases en GitHub con binarios de plataforma nombrados
gitlab-mcp-server-{os}-{arch} - Incluye un asset
checksums.txtcon hashes SHA-256 (formato goreleaser)