API docs build has been failing since Aug 2021
frenchy64 opened this issue · 9 comments
According to https://github.com/google/closure-library/tree/gh-pages the gh-pages branch has not been updated since August 2021.
The master branch build seems to be failing.
eg., https://github.com/google/closure-library/runs/5234118841?check_suite_focus=true#step:6:539
Exception in thread "main" java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.
null
Node(RETURN): /home/runner/work/closure-library/closure-library/closure/goog/editor/plugins/basictextformatter.js:418:6
return this.queryCommandStateInternal_(
Parent(SCRIPT): /home/runner/work/closure-library/closure-library/closure/goog/editor/plugins/basictextformatter.js:11:0
goog.provide('goog.editor.plugins.BasicTextFormatter');
at com.google.javascript.jscomp.TypeCheck.visitReturn(TypeCheck.java:2664)
at com.google.javascript.jscomp.TypeCheck.visit(TypeCheck.java:642)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:867)
at com.google.javascript.jscomp.NodeTraversal.traverseChildren(NodeTraversal.java:979)
at com.google.javascript.jscomp.NodeTraversal.handleScript(NodeTraversal.java:804)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:839)
at com.google.javascript.jscomp.NodeTraversal.traverseChildren(NodeTraversal.java:979)
at com.google.javascript.jscomp.NodeTraversal.traverseBranch(NodeTraversal.java:863)
at com.google.javascript.jscomp.NodeTraversal.traverseWithScope(NodeTraversal.java:444)
at com.google.javascript.jscomp.TypeCheck.check(TypeCheck.java:486)
at com.google.javascript.jscomp.TypeCheck.process(TypeCheck.java:446)
at com.google.javascript.jscomp.DefaultPassConfig$50$1.process(DefaultPassConfig.java:1985)
at com.google.javascript.jscomp.PhaseOptimizer$NamedPass.process(PhaseOptimizer.java:326)
at com.google.javascript.jscomp.PhaseOptimizer.process(PhaseOptimizer.java:235)
at com.google.javascript.jscomp.Compiler.check(Compiler.java:1025)
at com.google.javascript.jscomp.Compiler.performChecksAndTranspilation(Compiler.java:825)
at com.google.javascript.jscomp.Compiler.lambda$stage1Passes$0(Compiler.java:755)
at com.google.javascript.jscomp.CompilerExecutor$2.call(CompilerExecutor.java:102)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.NullPointerException
... 22 more
The master build has failed since beacf42.
Based on the error message, I'd guess it's something related to the changes in goog/editor/plugins/basictextformatter.js.
beacf42#diff-e5074ddd88b79dfea4eea6b8613cf08009f76d429ae9086c6647f2d8c93590cc
This is because that commit introduced '??' into that file, and the release version of JSDossier we are using doesn't support that (as it is based off a very old version of Closure Compiler).
JSDossier is not being maintained any further at this time, so this might have to remain broken until someone can find the 20% time to try and fix this up (unlikely).
looks like new docs have been pushed 5ae9145
That's correct - we are aiming to push new docs alongside new NPM releases of the library.
We just pushed another version bump yesterday (99371f7), and once the corresponding processes all catch up and docs are pushed for that version I'll close this out.
does this mean JSDossier was fixed, or something else?
Something else: JSDossier's actual source of truth is Google's VCS (the GitHub repo is effectively a mirror), and we (Closure Library maintainers) now internally build and run the tool before exporting the results. The reason JSDossier keeps "breaking" is that it is deeply integrated with Closure Compiler internals (which change all the time), but the OSS builds of JSDossier aren't being kept in sync with Closure Compiler updates (e.g. support for new language syntax, typesystem changes etc).
I was thinking about making them searchable as a Dash docset. I’ll just plan on parsing the /api directory in gh-pages if it’ll be there after each version release.
That's the plan.
Note that this is all currently best-effort (especially as we don't have the bandwidth to maintain JSDossier itself at the moment, and it's unclear if we ever will). If changes to the docgen break your workflow then I'm sorry to say you will likely be stuck, especially as you wouldn't just be able to run (a relevant version of) jsdossier yourself. We don't plan any significant changes in the near future, but we also don't guarantee any stability in how the docs are implemented or displayed.