Documentation is not generated for a library
This is the issue with documentation site for Capybara Version: 2.13 https://www.rubydoc.info/gems/capybara/2.13.0/Capybara/
I expect to see the documentation for Capybara 2.13 when I visit the URL https://www.rubydoc.info/gems/capybara/2.13.0/Capybara/
The info message is shown instead
Processing capybara
capybara (2.13.0) is being processed. You'll be redirected when the pages are built, it shouldn't take much longer.
Despite trying several times during a day or even in one-week interval the message is still there.
Steps to reproduce
- Visit the URL https://www.rubydoc.info/gems/capybara/2.13.0/Capybara/
- Try again in a couple of hours - the message is still there
I raised an issue on Github, but community suggested that it's most likely an issue with rubydoc.info
https://github.com/teamcapybara/capybara/issues/2251
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by lsegal on 26 Sep, 2019 08:48 PM
Rubydoc has enabled sandboxed execution of YARD extensions, which it looks like Capybara is using, but we currently only support that execution during parsing and not generation. It looks like Capybara's extension is generating custom objects into the .yardoc database that cannot be deserialized by the generation layer, in other words, the extension expects the generation layer to use the same execution context as the parser. This works well for local execution but is problematic for our shared environment-- the right way to do this would be to not create custom objects but to rely on YARD's existing tag system to apply properties.
The TLDR here is that it doesn't seem like the 2.x gems are compatible for the time being. The good news is that the latest 3.x gem seems to work, but that may or may not help you if you're relying on older APIs that are no longer in 3.x.
If this is really a problem we can try to provide a one-off workaround here until we have a more long-term fix.