You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although we have the instructions in the README.md for everyone to pretty easily Preview the docs locally and test for errors, anecdotally I know not many contributors to the docs source regularly perform this check when they are making changes in a branch on this repository or on their fork in order to open a pull request.
This is becoming a more important step in proofreading and testing any changes beyond the most trivial, since we keep adding custom CSS, Mkdocs extensions and plugins, which means that the GitHub Flavored Markdown (GFM) rendering that you can see in the GitHub UI previews might not be a good representation of what is deployed. The divergence of the two is becoming greater.
Ideally, a bot would then post a comment in the PR with the URL containing the build, so that the author and any reviewers can conveniently double check the rendering of the changes contained in the pull request (without having to build it locally).
Nothing contained in this public repo is private, but if we wanted to host them on some URL behind an ANL/ALCF login, that would still be convenient and promote better code reviews versus the status quo.
The text was updated successfully, but these errors were encountered:
Although we have the instructions in the
README.md
for everyone to pretty easily Preview the docs locally and test for errors, anecdotally I know not many contributors to the docs source regularly perform this check when they are making changes in a branch on this repository or on their fork in order to open a pull request.This is becoming a more important step in proofreading and testing any changes beyond the most trivial, since we keep adding custom CSS, Mkdocs extensions and plugins, which means that the GitHub Flavored Markdown (GFM) rendering that you can see in the GitHub UI previews might not be a good representation of what is deployed. The divergence of the two is becoming greater.
It is trivial to extend the existing GitHub Actions workflow that runs the build step on the source branch and checks for errors to also deploy and render the changes like in
https://github.com/argonne-lcf/user-guides/blob/73405b588510ed7a132ffc4187c166f2e31dcd09/.github/workflows/update-livesite.yml
to another URL destination specified via
https://www.mkdocs.org/user-guide/deploying-your-docs/
or by changing the following lines
user-guides/mkdocs.yml
Lines 356 to 358 in 73405b5
Ideally, a bot would then post a comment in the PR with the URL containing the build, so that the author and any reviewers can conveniently double check the rendering of the changes contained in the pull request (without having to build it locally).
The only big question would be where to host these "temporary" docs. The most convenient would be a public URL such as
https://docs.alcf.anl.gov/reponame/branchname
https://docs.alcf.anl.gov/pull/ID/head
It would need to be excluded from Google Searches.
Nothing contained in this public repo is private, but if we wanted to host them on some URL behind an ANL/ALCF login, that would still be convenient and promote better code reviews versus the status quo.
The text was updated successfully, but these errors were encountered: