fix: réduit la concurrence uv pour le build Docker du backend
L'échec persistait malgré un timeout à 180s : le vrai problème est la bande passante limitée du runner CI, saturée par les 50 téléchargements uv en parallèle (défaut) — chaque paquet n'obtenait qu'une fraction du débit et finissait par expirer (constaté sur sqlalchemy, après 180s). Réduit UV_CONCURRENT_DOWNLOADS à 4 pour que chaque téléchargement avance réellement, et remonte le délai à 600s par sécurité. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
ac5710ffaf
commit
68d42ee303
+8
-4
@@ -13,10 +13,14 @@ ENV TZ=Europe/Paris \
|
|||||||
UV_COMPILE_BYTECODE=1 \
|
UV_COMPILE_BYTECODE=1 \
|
||||||
UV_PROJECT_ENVIRONMENT=/app/.venv \
|
UV_PROJECT_ENVIRONMENT=/app/.venv \
|
||||||
PATH="/app/.venv/bin:$PATH" \
|
PATH="/app/.venv/bin:$PATH" \
|
||||||
# Défaut 30s : trop court pour certains gros paquets (reportlab ->
|
# Le runner CI a une bande passante limitée : à 50 téléchargements uv en
|
||||||
# charset-normalizer) sur un runner CI à bande passante limitée, d'où
|
# parallèle (défaut), chacun n'obtient qu'une fraction du débit et finit
|
||||||
# les échecs "network timeout" en intégration.
|
# par dépasser même un timeout généreux ("network timeout" sur de gros
|
||||||
UV_HTTP_TIMEOUT=180
|
# paquets comme sqlalchemy/reportlab). On réduit la concurrence pour que
|
||||||
|
# chaque téléchargement avance réellement, et on garde une marge large
|
||||||
|
# sur le délai par requête.
|
||||||
|
UV_CONCURRENT_DOWNLOADS=4 \
|
||||||
|
UV_HTTP_TIMEOUT=600
|
||||||
|
|
||||||
WORKDIR /app
|
WORKDIR /app
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user