Nuevo en 0.4.22
Configurar CI para un repositorio
Abre CI/CD en la barra de navegación. Esta versión configura la integración continua; no despliega tu aplicación.
Los nombres de los controles que aparecen a continuación corresponden a la interfaz en inglés.
Antes de empezar
Un plan de pago y un repositorio con commits
Inicia sesión en Account con un plan de pago; cuenta una plaza en un equipo de pago Team, Business o Enterprise, pero no una prueba. La configuración necesita un servidor Termiyo accesible con las plantillas CI de 0.4.22. Envía un primer commit al repositorio antes de configurar CI.
11 tipos de proyecto
Build it as ofrece Node.js, Python, Go, Rust, Java (Maven), Java (Gradle), Ruby, PHP, .NET, Docker image y A blank starting point. La detección de GitHub y GitLab lee los nombres de archivo en la raíz del repositorio; comprueba la selección y elige una si hay varias coincidencias. El punto de partida en blanco contiene un paso de ejemplo que debes sustituir.
GitHub
1. Prepara un token
Selecciona GitHub y pulsa Open GitHub’s token page. Usa un token de acceso personal de permisos detallados limitado al repositorio: Contents, Workflows y Pull requests necesitan Read and write; Actions y Metadata necesitan Read. Establece una caducidad de 90 días o menos. Solo se admite github.com a través de api.github.com; GitHub Enterprise no es compatible.
2. Guarda y comprueba
Elige Saved token o pulsa Save a new token, completa Name y Paste the token, y pulsa Save to key box. En Repository, introduce owner/name o el enlace de github.com y pulsa Check. También puedes usar List repositories this token can see.
3. Revisa y abre la pull request
Elige Build it as, pulsa Show the file, revisa el archivo y pulsa Set up CI. Termiyo crea un commit de .github/workflows/termiyo-ci.yml en termiyo/ci-setup y abre una pull request. Usa Open in browser para revisarla y fusionarla. CI puede ejecutarse en la pull request; la rama predeterminada no cambia hasta que alguien la fusiona.
GitLab
1. Indica el proyecto y prepara un token
Selecciona GitLab. En Project, introduce group/project para gitlab.com o la URL HTTPS completa del proyecto de tu propio GitLab y pulsa Open GitLab’s token page. Usa un token de acceso personal o de proyecto con el alcance api; este permite todo lo que puede hacer su propietario, así que usa una caducidad corta y revoca el token después de configurar CI.
2. Comprueba el proyecto y los runners
Elige Saved token o usa Save a new token → Save to key box y pulsa Check. Elige Build it as. Si no hay ningún runner disponible, activa los runners compartidos o registra uno del proyecto antes de fusionar; el panel también indica cuándo el token no permite determinar si hay un runner disponible.
3. Revisa y abre la merge request
Pulsa Show the file, revisa el archivo y pulsa Set up CI. Termiyo crea un commit de .gitlab-ci.yml en termiyo/ci-setup y abre una merge request. Usa Open in browser para revisarla y fusionarla; la rama predeterminada no cambia hasta la fusión.
Giti: Repos on a host
1. Comprueba el host
Conéctate al host SSH que guarda tu repositorio Giti y elige Repos on a host. Este runner necesita Linux en x86_64 o ARM64, git y Docker utilizable por la cuenta SSH, además de curl o wget, tar, sha256sum o shasum y timeout. Termiyo no instala Docker; consulta al administrador del host o usa Docker sin root.
2. Instala y activa
Pulsa Install the CI runner. Termiyo descarga nektos/act 0.2.89 en ~/.termiyo/bin y verifica su SHA-256 antes de descomprimirlo o ejecutarlo. Para el repositorio, elige Build it as y pulsa Turn CI on. Un hook post-receive existente de otra herramienta se deja intacto e impide la configuración automática.
3. Fusiona, envía y consulta el resultado
Si Termiyo creó la rama del flujo termiyo/ci, usa Copy para copiar los comandos mostrados y ejecútalos en tu clon, en la rama predeterminada, para fusionarla y hacer push. El host ejecuta entonces .github/workflows/termiyo-ci.yml con act en Docker tras los pushes del propietario; los pushes de compañeros con acceso concedido nunca inician CI. Usa Refresh y Log para consultar los resultados y Turn CI off para desactivar el hook.
Recursos de tu host
Cada ejecución tiene un límite de 30 minutos. Termiyo solicita a Docker la red bridge, ningún socket Docker dentro del trabajo, ningún privilegio nuevo y límites de 2 CPU, 4 GB de memoria y 512 procesos; que se cumplan depende del Docker del host. La primera ejecución descarga una imagen de 2,3 GB.
Límites y verificación
Flujos existentes y planes
En GitHub y GitLab, Termiyo nunca sobrescribe el archivo de flujo de destino; si existe .gitlab-ci.yml, ofrece una plantilla para integrar manualmente. El plan de pago cubre la configuración desde Termiyo: consultar ejecuciones no está restringido por el plan, y la CI ya configurada sigue funcionando cuando termina tu plan. Las plantillas proceden del servidor de Termiyo y deben coincidir con las huellas fijadas en la aplicación.
Validación hasta ahora
La configuración de GitHub y GitLab se ha probado con simulaciones, no con cuentas reales. Giti CI ha completado una ejecución real en un host x86_64. El despliegue no está implementado en esta versión.