Sim. Mudei o critério de parada automática padrão para max_batches=1 algumas semanas atrás também, o que não ajudou.

Eu gosto das soluções que você listou! Mais um de minha autoria:

1. Adicione algum código oculto no bloco de notas que pularia os cálculos de longa execução. Pode ser um código que simula o ajuste / previsão do pipeline. Vantagem: funciona. Desvantagem: pode não corresponder ao que os usuários obtêm quando executam manualmente, além disso, o código oculto pode ser confuso.
2. Para notebooks de longa duração, execute previamente localmente uma vez e salve a saída no notebook. O Nbsphinx usará uma execução salva, se houver, em vez de uma nova execução. Vantagem: funciona. Desvantagem: podemos esquecer de atualizar periodicamente a saída.
3. Simplifique / exclua parte do conteúdo do notebook. Por exemplo, considere reduzir o tamanho dos dados, critérios de parada, etc., se possível. Vantagem: acelerações. Desvantagem: não é possível mostrar a saída completa para alguns exemplos, como texto.

Eu recomendo ir com a opção 2, mas com a opção 3 em mente.

1627 foi fechado como uma duplicata, mas acho que ainda pode haver algo lá que não foi abordado neste problema, então poste aqui:

Percebi que os documentos estão demorando muito mais para serem compilados. Acho que isso é provável porque os documentos automl foram alterados em c871f3b para usar o conjunto de dados de fraude, em vez do conjunto de dados de câncer de mama (+ em outro lugar?) Para mostrar infer_problem_types, uma vez que o conjunto de dados de câncer de mama tem apenas colunas numéricas.

Suspeito que esse seja um problema / motivo diferente para o tempo de compilação ainda mais longo de documentos, dos 20 minutos anteriores até agora> 30 minutos, e vale a pena mencionar!

@dsherry FYI

Outra solução possível é usar vários processadores para criar os documentos:

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

Atualize a discussão a seguir com @dsherry.

Adicionar a bandeira -j ao nosso Makefile permite que o teste build docs no circleci termine mais rápido, como visto aqui . Infelizmente, ReadtheDocs não executa esse comando, o que significa que a geração real da documentação publicada ainda demora um pouco e costuma gerar erros.

Esta é a aparência de uma construção bem-sucedida para ReadtheDocs, levando um pouco mais de 20 minutos para ser concluída. As diferenças entre os tempos de construção HTML e Latex sugerem que construir os blocos de anotações Jupyter em si não leva muito tempo, o que é bom.

No entanto, também estamos encontrando casos em que a construção falhar como este . Percebemos que, por algum motivo, ReadtheDocs está executando a sequência completa de comandos duas vezes, o que faz com que a compilação demore muito mais (bem mais de 30 minutos cada para criar os arquivos HTML e latex) e faz com que a compilação do documento falhe. Farei o acompanhamento com a equipe de suporte do ReadtheDocs para ver por que isso está acontecendo e como podemos corrigir isso, e atualizarei esses resultados aqui quando receber feedback.

@ bchen1116 contatou o suporte e eles disseram

Parece que a causa subjacente desse bug é o número de versões ativas que você possui. Vejo alguns erros em nossos registros relacionados a isso.
Para contornar isso por enquanto, você pode reduzir o número de versões ativas que mantém. Parece que você está criando versões para branches individuais ou solicitações pull. Você já experimentou nosso recurso de criação de solicitações pull? Isso ajudaria a remover as versões desnecessárias após a compilação, mantendo o conteúdo compilado.

Acredito que o "recurso de criação de solicitação de pull" referenciado aqui é este , confirmando.

Atualizar:
Atualizamos o RTD para compilar apenas a partir de solicitações pull, removendo as compilações desnecessárias para diferentes versões (branches) que enviamos. Além disso, excluímos todas as versões desnecessárias (não marcadas) do RTD (ramos diversos que usamos para PRs), o que parece ter ajudado na construção do documento. Não notamos que nenhum documento está expirando nas compilações, então fecharemos este problema amanhã, a menos que comecemos a ver os tempos limite novamente.

@ bchen1116 isso fechado agora?

Fechando agora, já que não houve problemas com compilações lentas de documentos.