Ага. Пару недель назад я также изменил критерий остановки автомата по умолчанию на max_batches=1 , что не помогло.

Мне нравятся перечисленные вами решения! Плюс один мой собственный:

1. Добавьте в блокнот скрытый код, который пропустит длительные вычисления. Это может быть код, который имитирует соответствие / прогнозирование конвейера. Преимущество: работает. Недостаток: может не совпадать с тем, что пользователи получают при запуске вручную, плюс скрытый код сбивает с толку.
2. Для ноутбуков с длительным сроком эксплуатации выполните предварительный запуск локально один раз и сохраните результат в ноутбуке. Nbsphinx будет использовать сохраненное выполнение, если оно существует, вместо повторного запуска. Преимущество: работает. Недостаток: мы можем забывать периодически обновлять вывод.
3. Упростите / удалите часть содержимого записной книжки. Например, если возможно, рассмотрите возможность уменьшения размера данных, критерия остановки и т. Д. Преимущество: ускорения. Недостаток: для некоторых примеров, например текста, не отображается полный вывод.

Я рекомендую выбрать вариант 2, но помня о варианте 3.

1627 был закрыт как дубликат, но я думаю, что там все еще может быть что-то, что не было затронуто в этой проблеме, поэтому разместите здесь:

Я заметил, что создание документов занимает гораздо больше времени. Я думаю, это вероятно потому, что в c871f3b были изменены документы automl для использования набора данных о мошенничестве вместо набора данных о раке груди (+ где-то еще?) Для демонстрации infer_problem_types, поскольку набор данных о раке груди имеет только числовые столбцы.

Я подозреваю, что это другая проблема / причина того, что время сборки документов еще больше, с предыдущих 20 минут до настоящего времени> 30 минут, и, возможно, стоит упомянуть!

@dsherry FYI

Другое возможное решение - использовать несколько процессоров для создания документов:

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

Обновите после обсуждения с @dsherry.

Добавление флага -j к нашему Makefile позволяет тесту build docs на circleci завершиться быстрее, как показано здесь . К сожалению, ReadtheDocs не запускает эту команду, а это означает, что фактическое создание опубликованной документации все еще требует времени и часто приводит к ошибкам.

Вот как выглядит успешная сборка ReadtheDocs, для завершения которой требуется чуть более 20 минут. Различия между временем сборки HTML и Latex говорят о том, что сборка самих блокнотов Jupyter не займет много времени, и это хорошо.

Тем не менее, мы также найти примеры , когда сборка не удается , как это . Мы заметили, что по какой-то причине ReadtheDocs дважды запускает полную последовательность команд, что приводит к тому, что сборка занимает гораздо больше времени (более 30 минут каждая для создания файлов HTML и latex) и приводит к сбою сборки документа. Я свяжусь с группой поддержки ReadtheDocs, чтобы узнать, почему это происходит и как мы можем это исправить, и я обновлю эти результаты здесь, когда получу отзыв.

@ bchen1116 обратился в

Похоже, что основная причина этой ошибки - количество имеющихся у вас активных версий. Я вижу в наших журналах несколько ошибок, связанных с этим.
Чтобы обойти это сейчас, вы можете уменьшить количество сохраняемых активных версий. Похоже, вы создаете версии для отдельных веток или запросов на вытягивание, пробовали ли вы нашу функцию создания запросов на вытягивание? Это поможет удалить ненужные версии после сборки, сохранив при этом созданный контент.

Я считаю , что «тянуть запрос здание функция» ссылка здесь это , подтверждая.

Обновлять:
Мы обновили RTD для сборки только на основе запросов на вытягивание, удалив ненужные сборки для разных версий (веток), которые мы отправляем. Кроме того, мы удалили все ненужные (немаркированные) версии из RTD (разные ветки, которые мы используем для PR), что, похоже, помогло сборкам документов. Мы не замечаем, что время ожидания документов для сборок истекает, поэтому мы закроем эту проблему завтра, если время ожидания снова не начнется.

@ bchen1116 это сейчас

Закрытие, так как не было проблем с медленной сборкой документов.