Skip to content

chore: increase build resources faq #147

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mjroson merged 2 commits into from
Feb 11, 2026
Merged

chore: increase build resources faq #147

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7493ecb
chore: increase build resources FAQ
lucaiz Feb 10, 2026
fffd0d8
fix: added instruction to check logs fist
lucaiz Feb 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions content/docs/en/project/build/build.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,3 +27,25 @@ Remember that you need a Build to update the code that the Deployment runs insid
SleakOps has its own CLI Tool that you can use to automate Builds and Deployments in your CI/CD. More info [here](/docs/cli).

:::

## FAQs

<details>
<summary>
### Why is my build failing or getting killed?
</summary>

:::info Check Logs First
Before assuming it's a resource issue, check your build logs to identify the actual cause of failure. Look for specific error messages that indicate resource constraints like `OOMKilled` or resource limit errors.
:::

If your build process is failing unexpectedly or being terminated, it's often due to insufficient resources (CPU or memory) allocated for the build process. The Pod running the build may be killed by Kubernetes when it exceeds the configured resource limits.

**Common symptoms:**
- Build fails with OOMKilled (Out of Memory) errors
- Build process stops mid-execution without clear error messages
- Build is extremely slow or appears frozen

**Solution:**
Increase the build resources in **Project** → **Settings** → **Deploy Build Resources**. See the [Deploy Build Resources](/docs/project/build_resources) documentation for detailed instructions on how to adjust CPU and memory allocations.
</details>
62 changes: 61 additions & 1 deletion content/docs/en/project/build_resources.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,4 +48,64 @@ Configure the resources allocated during the deployment process:

:::warning Resource Limits
- Ensure your cluster has sufficient resources to accommodate the requested allocations
:::
:::

## FAQs

<details>
<summary>
### What happens if my build or deployment exceeds the configured resources?
</summary>

:::info Check Logs First
Before adjusting resources, always check your build and deployment logs to confirm that resource constraints are the actual cause of the failure. Look for specific error messages like `OOMKilled` or resource limit indicators.
:::

When a build or deployment process consumes more CPU or memory than the configured request values, the Pod executing the process may be terminated by Kubernetes before completion. This results in:

- **Failed builds**: The build process stops mid-execution and fails to produce a Docker image
- **Failed deployments**: The deployment process is interrupted and doesn't complete successfully
- **Error messages**: You'll see errors indicating that the Pod was terminated due to resource constraints (OOMKilled for memory or CPU throttling)

This is a common issue when dealing with:
- Large codebases that require significant memory during compilation
- Complex build processes with multiple dependencies
- Projects with extensive testing or bundling steps
</details>

<details>
<summary>
### How do I increase build and deployment resources?
</summary>
If you're experiencing build or deployment failures due to resource constraints, you can increase the allocated resources:

1. Navigate to **Project** → **Settings** in the SleakOps interface
2. Select **Deploy Build Resources** from the settings menu
3. Increase the values for the resource that's causing issues:
- **Build Request CPU**: Increase if builds are slow or CPU-throttled
- **Build Request Memory**: Increase if builds fail with OOMKilled errors
- **Deploy Request CPU**: Increase if deployments are slow
- **Deploy Request Memory**: Increase if deployments fail during the process
4. Click **Save** to apply the changes
5. Trigger a new build or deployment to use the updated resource allocations

:::tip Finding the Right Values
- Start by doubling the current values if you're experiencing failures
- Monitor the actual resource usage during builds/deployments
- Adjust incrementally until builds complete successfully
- Remember that higher values may impact costs and cluster capacity
:::
</details>

<details>
<summary>
### How do I know what values to set?
</summary>
Start with the default values and adjust based on observed behavior:

- If builds fail with **OOMKilled** errors, increase **Build Request Memory** (try 2Gi, 4Gi, or higher)
- If builds are **very slow**, increase **Build Request CPU** (try 1000m, 2000m, or higher)
- If deployments fail or timeout, increase the corresponding **Deploy Request** values

Monitor your build and deployment logs to identify resource-related issues and adjust accordingly.
</details>
24 changes: 23 additions & 1 deletion content/docs/es/project/build/build.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,4 +26,26 @@ Remember that you need a Build to update the code that the Deployment runs insid

SleakOps has its own CLI Tool that you can use to automate Builds and Deployments in your CI/CD. More info [here](/docs/cli).

:::
:::

## FAQs

<details>
<summary>
### ¿Por qué mi build está fallando o siendo terminado?
</summary>

:::info Revisa los Logs Primero
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](/docs/project/build_resources) para instrucciones detalladas sobre cómo ajustar las asignaciones de CPU y memoria.
Comment on lines +49 to +50
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# Check how links are structured in Spanish docs
echo "=== Links in Spanish docs ==="
rg -n '\(/docs/' content/docs/es/ --glob '*.mdx' | head -30

echo ""
echo "=== Check docusaurus config ==="
fd -t f 'docusaurus.config' -o 'docusaurus.config.js' | head -5

Repository: sleakops/docs

Length of output: 6322

🏁 Script executed:

# Look for i18n configuration
echo "=== Search for i18n config files ==="
fd -t f -e json -e js | grep -i 'i18n\|config' | head -20

echo ""
echo "=== Check main config directory ==="
ls -la | grep -E '(docusaurus|config|src)'

Repository: sleakops/docs

Length of output: 506

🏁 Script executed:

cat docusaurus.config.js

Repository: sleakops/docs

Length of output: 4848

🏁 Script executed:

cat -n content/docs/es/project/build/build.mdx | sed -n '45,55p'

Repository: sleakops/docs

Length of output: 604

🏁 Script executed:

# Check if the target file exists
find content/docs -name "*build_resource*" -o -name "*build-resource*"

echo ""
echo "=== Check how other Spanish docs link to English content ==="
# Look for patterns of linking from Spanish to other Spanish docs
rg 'build_resources|build-resources' content/docs/es/

Repository: sleakops/docs

Length of output: 513

🏁 Script executed:

# Check if Spanish docs typically use absolute /docs/ links or relative links
echo "=== Sample of links in Spanish docs (first 10) ==="
rg '\[.*\]\(/docs/' content/docs/es/ --glob '*.mdx' | head -10

echo ""
echo "=== Check if there are any es-prefixed links in Spanish docs ==="
rg '\[.*\]\(/es/docs/' content/docs/es/ --glob '*.mdx' | head -5

echo ""
echo "=== Check links without leading slash (relative) ==="
rg '\[.*\]\((?!/)[^)]+\)' content/docs/es/project/build/build.mdx

Repository: sleakops/docs

Length of output: 2901

🏁 Script executed:

# Check the learned pattern: look at a related file from the learning to see if similar structure exists
cat -n content/docs/es/project/dependency/index.mdx | sed -n '75,85p'

Repository: sleakops/docs

Length of output: 354

Arreglar el enlace para que resuelva correctamente en la versión en español de la documentación.

En Docusaurus con i18n configurado, el enlace /docs/project/build_resources es una ruta absoluta que dirigirá a la versión en inglés. Dado que el archivo destino existe en español (content/docs/es/project/build_resources.mdx), el enlace debería usar una ruta relativa o incluir el prefijo de locale /es/docs/project/build_resources para mantener al usuario en la documentación en español.

🤖 Prompt for AI Agents 
In `@content/docs/es/project/build/build.mdx` around lines 49 - 50, El enlace en
build.mdx apunta a la ruta absoluta "/docs/project/build_resources" que rompe la
navegación i18n; actualiza el enlace en content/docs/es/project/build/build.mdx
para que apunte a la versión en español reemplazando
"/docs/project/build_resources" por una ruta relativa (por ejemplo
"../build_resources" o "./build_resources") o por la ruta con prefijo de locale
"/es/docs/project/build_resources" para que resuelva correctamente al archivo
content/docs/es/project/build_resources.mdx.

</details>
62 changes: 61 additions & 1 deletion content/docs/es/project/build_resources.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,4 +48,64 @@ Configura los recursos asignados durante el proceso de despliegue:

:::warning Límites de Recursos
- Asegúrate de que tu clúster tenga recursos suficientes para acomodar las asignaciones solicitadas
:::
:::

## FAQs

<details>
<summary>
### ¿Qué sucede si mi build o deployment excede los recursos configurados?
</summary>

:::info Revisa los Logs Primero
Antes de ajustar recursos, siempre revisa tus logs de build y deployment para confirmar que las restricciones de recursos son la causa real del fallo. Busca mensajes de error específicos como `OOMKilled` o indicadores de límites de recursos.
:::

Cuando un proceso de build o deployment consume más CPU o memoria que los valores de solicitud configurados, el Pod que ejecuta el proceso puede ser terminado por Kubernetes antes de completarse. Esto resulta en:

- **Builds fallidos**: El proceso de build se detiene a mitad de ejecución y no logra producir una imagen Docker
- **Deployments fallidos**: El proceso de deployment se interrumpe y no se completa exitosamente
- **Mensajes de error**: Verás errores indicando que el Pod fue terminado debido a restricciones de recursos (OOMKilled para memoria o throttling de CPU)

Este es un problema común cuando se trabaja con:
- Bases de código grandes que requieren memoria significativa durante la compilación
- Procesos de build complejos con múltiples dependencias
- Proyectos con pasos extensos de testing o bundling
</details>

<details>
<summary>
### ¿Cómo aumento los recursos de build y deployment?
</summary>
Si estás experimentando fallos en builds o deployments debido a restricciones de recursos, puedes aumentar los recursos asignados:

1. Navega a **Proyecto** → **Configuración** en la interfaz de SleakOps
2. Selecciona **Deploy Build Resources** del menú de configuración
3. Aumenta los valores para el recurso que está causando problemas:
- **Build Request CPU**: Aumenta si los builds son lentos o sufren throttling de CPU
- **Build Request Memory**: Aumenta si los builds fallan con errores OOMKilled
- **Deploy Request CPU**: Aumenta si los deployments son lentos
- **Deploy Request Memory**: Aumenta si los deployments fallan durante el proceso
4. Haz clic en **Save** para aplicar los cambios
5. Dispara un nuevo build o deployment para usar las asignaciones de recursos actualizadas

:::tip Encontrando los Valores Correctos
- Comienza duplicando los valores actuales si estás experimentando fallos
- Monitorea el uso real de recursos durante builds/deployments
- Ajusta de forma incremental hasta que los builds se completen exitosamente
- Recuerda que valores más altos pueden impactar los costos y la capacidad del clúster
:::
</details>

<details>
<summary>
### ¿Cómo sé qué valores configurar?
</summary>
Comienza con los valores por defecto y ajusta basándote en el comportamiento observado:

- Si los builds fallan con errores **OOMKilled**, aumenta **Build Request Memory** (prueba con 2Gi, 4Gi, o más)
- Si los builds son **muy lentos**, aumenta **Build Request CPU** (prueba con 1000m, 2000m, o más)
- Si los deployments fallan o expiran, aumenta los valores correspondientes de **Deploy Request**

Monitorea tus logs de build y deployment para identificar problemas relacionados con recursos y ajusta en consecuencia.
</details>
22 changes: 22 additions & 0 deletions docs/project/build/build.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,3 +27,25 @@ Remember that you need a Build to update the code that the Deployment runs insid
SleakOps has its own CLI Tool that you can use to automate Builds and Deployments in your CI/CD. More info [here](/docs/cli).

:::

## FAQs

<details>
<summary>
### Why is my build failing or getting killed?
</summary>

:::info Check Logs First
Before assuming it's a resource issue, check your build logs to identify the actual cause of failure. Look for specific error messages that indicate resource constraints like `OOMKilled` or resource limit errors.
:::

If your build process is failing unexpectedly or being terminated, it's often due to insufficient resources (CPU or memory) allocated for the build process. The Pod running the build may be killed by Kubernetes when it exceeds the configured resource limits.

**Common symptoms:**
- Build fails with OOMKilled (Out of Memory) errors
- Build process stops mid-execution without clear error messages
- Build is extremely slow or appears frozen

**Solution:**
Increase the build resources in **Project** → **Settings** → **Deploy Build Resources**. See the [Deploy Build Resources](/docs/project/build_resources) documentation for detailed instructions on how to adjust CPU and memory allocations.
</details>
62 changes: 61 additions & 1 deletion docs/project/build_resources.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,4 +48,64 @@ Configure the resources allocated during the deployment process:

:::warning Resource Limits
- Ensure your cluster has sufficient resources to accommodate the requested allocations
:::
:::

## FAQs

<details>
<summary>
### What happens if my build or deployment exceeds the configured resources?
</summary>

:::info Check Logs First
Before adjusting resources, always check your build and deployment logs to confirm that resource constraints are the actual cause of the failure. Look for specific error messages like `OOMKilled` or resource limit indicators.
:::

When a build or deployment process consumes more CPU or memory than the configured request values, the Pod executing the process may be terminated by Kubernetes before completion. This results in:

- **Failed builds**: The build process stops mid-execution and fails to produce a Docker image
- **Failed deployments**: The deployment process is interrupted and doesn't complete successfully
- **Error messages**: You'll see errors indicating that the Pod was terminated due to resource constraints (OOMKilled for memory or CPU throttling)

This is a common issue when dealing with:
- Large codebases that require significant memory during compilation
- Complex build processes with multiple dependencies
- Projects with extensive testing or bundling steps
</details>

<details>
<summary>
### How do I increase build and deployment resources?
</summary>
If you're experiencing build or deployment failures due to resource constraints, you can increase the allocated resources:

1. Navigate to **Project** → **Settings** in the SleakOps interface
2. Select **Deploy Build Resources** from the settings menu
3. Increase the values for the resource that's causing issues:
- **Build Request CPU**: Increase if builds are slow or CPU-throttled
- **Build Request Memory**: Increase if builds fail with OOMKilled errors
- **Deploy Request CPU**: Increase if deployments are slow
- **Deploy Request Memory**: Increase if deployments fail during the process
4. Click **Save** to apply the changes
5. Trigger a new build or deployment to use the updated resource allocations

:::tip Finding the Right Values
- Start by doubling the current values if you're experiencing failures
- Monitor the actual resource usage during builds/deployments
- Adjust incrementally until builds complete successfully
- Remember that higher values may impact costs and cluster capacity
:::
</details>

<details>
<summary>
### How do I know what values to set?
</summary>
Start with the default values and adjust based on observed behavior:

- If builds fail with **OOMKilled** errors, increase **Build Request Memory** (try 2Gi, 4Gi, or higher)
- If builds are **very slow**, increase **Build Request CPU** (try 1000m, 2000m, or higher)
- If deployments fail or timeout, increase the corresponding **Deploy Request** values

Monitor your build and deployment logs to identify resource-related issues and adjust accordingly.
</details>