Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#15455 closed enhancement (wontfix)

Interrupt documentation build on error

Reported by: vbraun Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: documentation Keywords:
Cc: Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: u/vbraun/docbuild_error (Commits, GitHub, GitLab) Commit: f6accfaf41b9b10f83ee2c68ed8d8889de7604cb
Dependencies: Stopgaps:

Status badges

Description

Interrupt documentation building if an error is encountered. Aso, search output for more error conditions (equivalent to Jeroen's release manager script).

Change History (14)

comment:1 Changed 8 years ago by vbraun

  • Branch set to u/vbraun/docbuild_error

comment:2 Changed 8 years ago by git

  • Commit set to f6accfaf41b9b10f83ee2c68ed8d8889de7604cb

Branch pushed to git repo; I updated commit sha1. New commits:

f6accfabe less strict during inventory build

comment:3 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:4 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:5 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:6 Changed 6 years ago by jdemeyer

  • Authors Volker Braun deleted
  • Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
  • Reviewers set to Jeroen Demeyer
  • Status changed from new to needs_review

Isn't this already happening?

comment:7 Changed 6 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:8 Changed 6 years ago by vbraun

No, concurrent workers are not interrupted. Especially PDF build errors are typically sandwiched between 1000's of lines of unrelated output.

comment:9 Changed 6 years ago by jhpalmieri

I'm not sure I would want concurrent workers interrupted, at least for html docs. If reference/combinat is 90% done and going to build correctly and the error is somewhere else, I want to be able to try to fix the error and then not have to wait for combinat to build again from scratch.

This might be more useful for the PDF docs, since I don't think the docbuilder does a good job of detecting whether the docs have been successfully built already.

comment:10 Changed 6 years ago by vbraun

Of course the annoyance factor depends on how much the concurrent jobs spew out. In a makefile, gcc will only add a line or so which is negligible. But you really want to see the error within the last ~50 lines, everything else is imho very confusing. The thousands of lines of PDF output easily flood the scrollback buffer, that I'd call a total disaster.

comment:11 Changed 6 years ago by jhpalmieri

Fortunately, the PDF build is logged. If the PDF build fails, maybe we could get better error-reporting: report, for example, if there is a (recent?) LaTeX file in output/latex/en/reference/MODULE/ but no PDF file in output/pdf/en/reference/MODULE/. Or switch to a serial build to isolate the problem.

Comparing with make, I don't want make to interrupt concurrent workers, so I don't think I want docbuilding to do this, either.

comment:12 Changed 6 years ago by vbraun

Its a recurring pain point that people fail to find the errors in their PDF file, but I guess it just hurts to be stupid.

comment:13 Changed 6 years ago by vbraun

  • Resolution set to wontfix
  • Status changed from positive_review to closed

comment:14 Changed 6 years ago by jdemeyer

Huh? I thought you disagreed with closing this?

Note: See TracTickets for help on using tickets.