Build
Ya hablamos del Build tanto en la documentación de Proyecto como en la documentación del Build inicial. Un build es, básicamente, una plantilla del sistema operativo, las librerías y demás dependencias del proyecto que vas a desplegar.
Creación de un Build
Para crear un Build solo el campo Project es obligatorio; los otros tres son opcionales y toman un valor por defecto si no los completás:
- Project: hace referencia a lo que llamamos ProjectEnv; acá elegís qué ProjectEnv querés buildear.
- Branch: te permite elegir cualquier branch del repositorio que hayas elegido como Project. Por defecto, el nombre del Environment.
- Commit hash: también podés elegir el commit para buildear un commit específico en lugar del último, que es lo que hacemos por defecto. Por defecto, el último commit.
- Tag: simplemente un tag para diferenciar builds. Por defecto, 'latest'.
¿Por qué necesitamos buildear una imagen de Docker?
Como usamos Helm charts , necesitamos la imagen porque es lo que usan para desplegar un Release de Kubernetes.
Recordá que necesitás un Build para actualizar el código que el Deployment ejecuta dentro del Cluster de Kubernetes.
SleakOps tiene su propia herramienta de CLI que podés usar para automatizar Builds y Deployments en tu CI/CD. Más info acá.
Tiempo límite de build (timeout)
Cada build se ejecuta con un tiempo de vida máximo. Si un build se queda trabado — esperando un lock, descargando una imagen que nunca llega, o repitiéndose dentro de un paso del build — SleakOps lo detiene automáticamente y lo marca como fallido, en lugar de dejarlo correr indefinidamente. Si no definís un límite, se aplica un valor por defecto de 180 minutos, de modo que todo build siempre tiene un tope.
Definí el límite por build desde la CLI de SleakOps con la opción --timeout, en minutos:
sleakops build --project my-app --branch main --timeout 30
Valor de --timeout | Efecto |
|---|---|
| Omitido | Se aplica el valor por defecto de 180 minutos. |
| Un número positivo | El build se detiene y se marca como fallido luego de esa cantidad de minutos. |
0 | El build igual queda acotado por el valor por defecto de la plataforma. Con --wait, además quita el límite de espera de la CLI, que entonces espera hasta que el build termine; sin --wait se comporta como omitir --timeout. |
Combinado con --wait, --timeout también limita cuánto espera la CLI a que el build termine antes de salir con error. Esto es útil en pipelines de CI/CD, donde un build trabado bloquearía el job indefinidamente:
sleakops build --project my-app --branch main --wait --timeout 30
Si el build no termina dentro del timeout, la CLI sale con un código distinto de cero para que el paso del pipeline falle rápido.
Para CI/CD, configurá --timeout con un valor un poco mayor a la duración normal de tu build. Así un build realmente trabado se detecta rápido, mientras que los builds sanos siempre tienen margen para terminar.
Preguntas frecuentes
¿Por qué mi build está fallando o siendo terminado?
Antes de asumir que es un problema de recursos, revisa tus logs de build para identificar la causa real del fallo. Busca mensajes de error específicos que indiquen restricciones de recursos como OOMKilled o errores de límites de recursos.
Si tu proceso de build está fallando inesperadamente o siendo terminado, a menudo se debe a recursos insuficientes (CPU o memoria) asignados para el proceso de build. El Pod que ejecuta el build puede ser eliminado por Kubernetes cuando excede los límites de recursos configurados.
Síntomas comunes:
- El build falla con errores OOMKilled (Out of Memory / Sin Memoria)
- El proceso de build se detiene a mitad de ejecución sin mensajes de error claros
- El build es extremadamente lento o parece congelado
Solución: Aumenta los recursos de build en Proyecto → Configuración → Deploy Build Resources. Consulta la documentación de Recursos de Deploy Build para instrucciones detalladas sobre cómo ajustar las asignaciones de CPU y memoria.