Skip to content

Conversation

@mofojed
Copy link
Member

@mofojed mofojed commented May 8, 2025

  • Run npm run update-doc-snapshots to extract all test-sets from docs, and then run them against the latest deephaven-core
    • Created a custom directive to pass through the info string on code blocks, because the default myst parser just drops them
    • Snapshots are outputted to docs/snapshots, then copied into the build/markdown folder when the docs are built
    • This PR does not include those snapshots yet, will have another PR just to check in those snapshots
    • Plotly express snapshots require some changes in Salmon to add a PlotlyExpressSerializer (I have this in another branch)
  • Tested with the update Salmon with a plotly express preview component: https://github.com/deephaven/salmon/pull/41

- Run `npm run update-doc-snapshots` to extract all test-sets from docs, and then run them against the latest deephaven-core
  - Created a custom directive to pass through the info string on code blocks, because the default myst parser just drops them
  - Snapshots are outputted to docs/snapshots, then copied into the build/markdown folder when the docs are built
  - This PR does not include those snapshots yet, will have another PR just to check in those snapshots
  - Plotly express snapshots require some changes in Salmon to add a PlotlyExpressSerializer (I have this in another branch)
@mofojed mofojed requested a review from mattrunyon May 8, 2025 21:33
@mofojed mofojed self-assigned this May 8, 2025
@github-actions github-actions bot requested a review from margaretkennedy May 8, 2025 21:33
volumes:
- ./plugins/ui/docs/build/markdown:/extract/ui
- ./plugins/plotly-express/docs/build/markdown:/extract/plotly-express
- ./docker/build/test-sets:/results # Output to a temporary build directory
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you could specify this as a docker volume at the top level of the compose file instead and then it won't need an intermediary directory on the host. The potential downside is less visibility into junk in this directory if it's not cleared by the extractor before running. Docker will create and manage the volume instead of using the host as a middleman.

volumes:
  test-sets:
services:
  extractor:
    volumes:
      - test-sets:/results

You can also still use the root volume definition to create a bind mount if you wanted it visible in the repo files. I think it works like this for the volume definition and then same to attach it to the service. The benefit of this would just be there's no accidental typo in the definition between the 2 containers, but that doesn't really matter in this case since it's only used twice

volumes:
  test-sets:
    driver: local
    driver_opts:
      o: bind
      device: ./docker/build/test-sets

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly Copilot suggested exactly this, but with type: none added to driver_opts. Docs from driver_opts show type being specified: https://docs.docker.com/reference/compose-file/volumes/#driver_opts
I'll try with omitting it though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So doing it this way throws an error if the directory doesn't already exist:

 ✔ deephaven-plugins-docs-validator Pulled                                                                                                                                                                                                  1.0s 
Error response from daemon: error while mounting volume '/var/lib/docker/volumes/deephaven-plugins_validator-results/_data': failed to mount local volume: mount /home/bender/dev/deephaven/iris-oss/deephaven-plugins/docker/build/validator-results:/var/lib/docker/volumes/deephaven-plugins_validator-results/_data, flags: 0x1000: no such file or directory ✔ deephaven-plugins-docs-validator Pulled                                                                                                                                                                                                  1.0s 
Error response from daemon: error while mounting volume '/var/lib/docker/volumes/deephaven-plugins_validator-results/_data': failed to mount local volume: mount /home/bender/dev/deephaven/iris-oss/deephaven-plugins/docker/build/validator-results:/var/lib/docker/volumes/deephaven-plugins_validator-results/_data, flags: 0x1000: no such file or directory

Not sure how to get around that without creating the directories first (outside of the docker compose file). It sounds like the path must exist for it to work: https://forums.docker.com/t/can-named-volume-in-docker-compose-file-create-a-folder-if-it-does-not-exist/143625

I think I'll just switch this back? Unless we want to git check-in those folders then ignore the contents...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing it which way doesn't work? The bind mount as a named volume?

I'm fine without it, just thought it was worth trying. Only 2 locations and it would throw or not work if they didn't match.

Or the non-bind named volume where Docker handles it and it doesn't create the intermediate test-set files in the repo. Unless you want easier inspection of the test-set files

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bind mount as a named volume doesn't work if the directory doesn't already exist.

@mofojed mofojed requested a review from mattrunyon May 13, 2025 13:03
mattrunyon
mattrunyon previously approved these changes May 13, 2025
Copy link
Collaborator

@mattrunyon mattrunyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good (assuming there wasn't an issue with the named volume bind mount)

@mofojed mofojed dismissed stale reviews from margaretkennedy and mattrunyon via 3f259e3 May 14, 2025 15:20
@mofojed mofojed requested a review from mattrunyon May 14, 2025 15:22
- Added snapshots for plotly-express/deephaven.ui
- Cleaned up issues in docs that were causing issues with snapshots
- Wired up a `--snapshots` action for taking snapshots of docs
@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

@github-actions
Copy link

ui docs preview (Available for 14 days)

]
volumes:
- ./plugins/ui/docs/build/markdown:/extract/ui
- ./plugins/plotly-express/docs/build/markdown:/extract/plotly-express
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattrunyon this is something that's kind of weird. So we're extracting the snapshots/generating them based on the built docs - main reason for this is if I include the source docs directory, then everything gets extracted twice (since the build directory is a descendent of the source directory). The other reason is to also verify that the generated docs actually have the correct order/test-set etc parameters set after generating.

Downside of this is the snapshots are in the docs source directory, and then need to be copied into the build directory for deploying to Salmon (or locally). So you need to 1. Build docs 2. Run snapshots 3. Copy snapshots into the build directory (we don't put them in there directly since we want them to persist).

Wondering if I should just test on the source directory instead? Would need to exclude the build directory, and we wouldn't catch issues with the code blocks potentially getting mutilated in the build step... any other ideas?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fine to run on source. The salmon validator on PRs will check if the build directory is invalid including snapshot issues.

The snapshot generator should only generate snapshots for those that don't exist, right? So most times you run it, it shouldn't actually create any files? Unless you add/modify code blocks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I've got it running on source now, and then copying over snapshots as part of the build.

@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

- Some orders not defined correctly
@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

@github-actions
Copy link

ui docs preview (Available for 14 days)

@github-actions
Copy link

ui docs preview (Available for 14 days)

@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

@github-actions
Copy link

ui docs preview (Available for 14 days)

Copy link
Collaborator

@mattrunyon mattrunyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The .dockerignore file needs to add **/docs and **/.tox. The cache is busting after generating new snapshots and causing a 2 min rebuild

Comment on lines +292 to +298
You can also re-generate the snapshots for the docs by passing the `--snapshots` flag. This should be done when new code blocks are added to the docs.
This example will build the docs for the `ui` plugin and re-generate the snapshots:
```shell
python tools/plugin_builder.py --docs --snapshots ui
```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a section about running this with npm as well? It looks like the flag just runs the npm script under the hood. Should we even make it a separate flag or just bake it into the --docs flag?

The annoying thing is how long the docker snapshot image takes to build. Takes me like 2.5-3 min. So I could see that being an argument for not running it with the docs flag

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I specifically had it as a separate flag as the snapshots container takes much longer to load if you haven't already built it.
I'll add a note about updating snapshots using npm...

mofojed added 2 commits May 21, 2025 10:33
- Now it doesn't rebuild everything when just updating the docs
@github-actions
Copy link

ui docs preview (Available for 14 days)

@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

@mofojed mofojed requested a review from mattrunyon May 21, 2025 15:06
@github-actions
Copy link

plotly-express docs preview (Available for 14 days)

@github-actions
Copy link

ui docs preview (Available for 14 days)

@mofojed mofojed merged commit 5b5ee61 into deephaven:main May 21, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet