-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add mechanism for verifying that source code in documentation is valid #7956
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @andygrove -- this is a great step forward
I ran build.sh
locally and it looks great to me
I have two suggestions:
- Add an error if there is an
include
that refers to a non existent example - Inline the examples in the doc and extract them for testing (though I don't feel strongly about this)
@@ -53,6 +60,25 @@ To make changes to the docs, simply make a Pull Request with your | |||
proposed changes as normal. When the PR is merged the docs will be | |||
automatically updated. | |||
|
|||
## Including Source Code | |||
|
|||
We want to make sure that all source code in the documentation is tested as part of the build and release process. We |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if you considered the opposite:
Leaving the code example inlined in the documentation, and extracting it out to datafusion-docs-test
with a script.
This would have the benefit that the markdown would be closer to the actual output documentation, and it might be easier to work on the examples inline.
The downside is that then we would need to somehow run a script to copy the examples into datafusion-docs-tests as part of CI to make sure they were up to date
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is more challenging because sometimes we are copying a whole function, and sometimes just a few lines of code, and some snippets depend on other snippets. It is also hard to write and test code with this approach because there is no IDE support.
@@ -21,8 +21,14 @@ | |||
set -e | |||
rm -rf build 2> /dev/null | |||
rm -rf temp 2> /dev/null | |||
|
|||
# copy source to temp dir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also a build.bat
file in this directory that might need to get updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I had missed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a convenient way to test on Windows, unfortunately
// print the plan | ||
println!("{}", plan.display_indent_schema()); | ||
``` | ||
<!-- include: library_logical_plan::create_plan --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested what happens if there is a bad link to an example here:
$ git diff
diff --git a/docs/source/library-user-guide/building-logical-plans.md b/docs/source/library-user-guide/building-logical-plans.md
index b75a788e83..6ae376d445 100644
--- a/docs/source/library-user-guide/building-logical-plans.md
+++ b/docs/source/library-user-guide/building-logical-plans.md
@@ -36,7 +36,7 @@ much easier to use the [LogicalPlanBuilder], which is described in the next sect
Here is an example of building a logical plan directly:
-<!-- include: library_logical_plan::create_plan -->
+<!-- include: library_logical_plan::create_planXXXXX -->
This example produces the following plan:
It seems to just leave a blank in the docs
Is there any way to generate an error in this case instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add some error checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this again and now the script simply doesn't change the section, which I think is fine
@alamb I have addressed the feedback. PTAL when you have time. |
I took the liberty of merging this branch to main. While I was testing it it turns out there are a bunch of clippy errors in the library code now such as
However, this PR seems not to trigger the full CI checks (probably because it only runs the docs workflow): https://github.com/apache/arrow-datafusion/blob/main/.github/workflows/docs_pr.yaml |
Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days. |
Which issue does this PR close?
Closes #7951
Rationale for this change
Adds a mechanism for ensuring that the documentation contains valid source code. See docs README in this PR for a description of the mechanism.
What changes are included in this PR?
include
directives in the markdownThis resulted in some small improvements to the documentation for the two pages that are updated to use this mechanism:
let mut
when creating contexts, and no longer useunwrap
cargo fmt
We can follow up with more PRs to move more code over. I suggest we create one PR per page to keep reviews short.
Are these changes tested?
Yes! Some code that was previously untested is now tested.
Are there any user-facing changes?
No