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_PROJECT_ENVIRONMENT=/app/.venv \
|
||||
PATH="/app/.venv/bin:$PATH" \
|
||||
# Défaut 30s : trop court pour certains gros paquets (reportlab ->
|
||||
# charset-normalizer) sur un runner CI à bande passante limitée, d'où
|
||||
# les échecs "network timeout" en intégration.
|
||||
UV_HTTP_TIMEOUT=180
|
||||
# Le runner CI a une bande passante limitée : à 50 téléchargements uv en
|
||||
# parallèle (défaut), chacun n'obtient qu'une fraction du débit et finit
|
||||
# par dépasser même un timeout généreux ("network timeout" sur de gros
|
||||
# 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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user