Sí. También cambié el criterio de detención automático predeterminado a max_batches=1 un par de semanas, lo que no ayudó.

¡Me gustan las soluciones que mencionaste! Más uno de los míos:

1. Agregue algún código oculto en el cuaderno que omitiría cálculos de larga ejecución. Este podría ser un código que simula el ajuste / predicción de la tubería. Ventaja: funciona. Desventaja: puede que no coincida con lo que obtienen los usuarios cuando ejecutan a mano, además, el código oculto es confuso.
2. Para portátiles de larga duración, ejecute previamente localmente una vez y guarde la salida en el portátil. Nbsphinx utilizará una ejecución guardada si existe una en lugar de volver a ejecutarla. Ventaja: funciona. Desventaja: es posible que olvidemos actualizar periódicamente la salida.
3. Simplifique / elimine parte del contenido del cuaderno. Por ejemplo, considere reducir el tamaño de los datos, detener el criterio, etc. si es posible. Ventaja: aceleraciones. Desventaja: no se puede mostrar el resultado completo de algunos ejemplos, como el texto.

Recomiendo que vayamos con la opción 2, pero con la opción 3 en mente.

1627 se cerró como un duplicado, pero creo que todavía podría haber algo allí que no se cubrió en este problema, así que publique aquí:

Noté que los documentos han tardado mucho más en compilarse. Creo que es probable que esto se deba a que los documentos automl se cambiaron en c871f3b para usar el conjunto de datos de fraude, en lugar del conjunto de datos de cáncer de mama (+ en otro lugar?) Para mostrar infer_problem_types, ya que el conjunto de datos de cáncer de mama solo tiene columnas numéricas.

Sospecho que este es un problema / motivo diferente para el tiempo de compilación aún más largo de los documentos, desde los 20 minutos anteriores hasta ahora> 30 minutos, ¡y podría valer la pena mencionarlo!

@dsherry FYI

Otra posible solución es utilizar varios procesadores para compilar los documentos:

https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption -sphinx-build-j

Actualice la siguiente discusión con @dsherry.

Agregar la bandera -j a nuestro Makefile permite que la prueba build docs en circleci termine más rápido, como se ve aquí . Desafortunadamente, ReadtheDocs no ejecuta este comando, lo que significa que la generación real de la documentación publicada todavía lleva un tiempo y, a menudo, se producen errores.

Así es como se ve una compilación exitosa para ReadtheDocs, y demora un poco más de 20 minutos en completarse. Las diferencias entre los tiempos de compilación de HTML y Latex sugieren que construir los propios cuadernos de Jupyter no requiere mucho tiempo, lo cual es bueno.

Sin embargo, también encontramos casos en los que la compilación falla de esta manera . Notamos que, por alguna razón, ReadtheDocs está ejecutando la secuencia completa de comandos dos veces, lo que hace que la compilación demore mucho más (más de 30 minutos cada uno para crear los archivos HTML y latex) y hace que falle la compilación del documento. Seguiré con el equipo de soporte de ReadtheDocs para ver por qué sucede esto y cómo podemos solucionarlo, y actualizaré con esos resultados aquí cuando reciba comentarios.

@ bchen1116 se puso en

Parece que la causa subyacente de este error es la cantidad de versiones activas que tiene. Veo algunos errores en nuestros registros relacionados con esto.
Para solucionar esto por ahora, puede reducir la cantidad de versiones activas que conserva. Parece que está creando versiones para sucursales individuales o solicitudes de extracción, ¿ha probado nuestra función de creación de solicitudes de extracción? Esto ayudaría a eliminar las versiones innecesarias después de la compilación, sin dejar de mantener el contenido compilado.

Creo que la "función de creación de solicitudes de extracción" a la que se hace referencia aquí es la siguiente , confirmando.

Actualizar:
Hemos actualizado RTD para compilar solo a partir de solicitudes de extracción, eliminando las compilaciones innecesarias en diferentes versiones (ramas) que impulsamos. Además, hemos eliminado todas las versiones innecesarias (sin etiquetar) de RTD (varias ramas que usamos para los RP), lo que parece haber ayudado a las compilaciones de documentos. No notamos que se agote el tiempo de espera de los documentos en las compilaciones, por lo que cerraremos este problema mañana a menos que comencemos a ver tiempos de espera nuevamente.

@ bchen1116, ¿esto se puede cerrar ahora?

Cerrando ahora, ya que no ha habido ningún problema con las compilaciones de documentos lentas.