Is your feature request related to a problem?
When submitting large/complex pull requests around documentation, I've been (reasonably) asked to submit a screenshot of the change. These are tedious to capture, the links in screenshots aren't clickable, the text isn't searchable, etc.
Describe the solution you'd like
When changes to a branch are pushed up, the documentation is built and available at a stable URL, a la ReadTheDocs. I believe the first part happens already via the Web and docs job in GitHub Actions, so I think it would mostly be a matter of deploying (and later cleaning up?) the built docs. https://pandas.pydata.org/docs/dev/ shows the latest on master, so maybe the URL structure is something like:
https://pandas.pydata.org/docs/preview/<user>/<branch>/
Bonus: Adding a commit status that links to the generated docs for that branch, as Netlify does.
API breaking implications
n/a
Describe alternatives you've considered
In one pull request, I:
- Generated the page
- Opened it in my browser
- Exported it as a PDF
- Uploaded it to Google Drive
- Changed the sharing settings
- Pasted the link in the comment
This solved the clickability/searchability problems, but is even more work than taking a screenshot.
Additional context
none
Comment From: afeld
Wrote something up about some other challenges to contributing to the pandas docs. Doing some brainstorming about how to make that workflow better overall.
Comment From: jreback
Wrote something up about some other challenges to contributing to the pandas docs. Doing some brainstorming about how to make that workflow better overall.
thanks for the mention!
Comment From: TomAugspurger
xref https://github.com/pandas-dev/pandas/issues/17921
We own the webserver, if we wanted to use that. We could push the built docs to the webserver on each PR, but would need a cron job to clean them up.
Or we can see if the built docs can be uploaded as an artifact to Azure Pipelines. Then post that URL somewhere. And also host it as a static site?
Comment From: alimcmaster1
xref #17921
We own the webserver, if we wanted to use that. We could push the built docs to the webserver on each PR, but would need a cron job to clean them up.
Or we can see if the built docs can be uploaded as an artifact to Azure Pipelines. Then post that URL somewhere. And also host it as a static site?
+1 for this.
Think Scikit-learn have a Github App that posts the artifact link directly in the PR. (This setup uses CircleCI) https://github.com/scikit-learn/scikit-learn/pull/14731
Azure approach would also work and we could host directly on azure? If we wanted to avoid upload to our webserver. https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deploy-pull-request-builds?view=azure-devops
Comment From: afeld
FYI that while ReadTheDocs supports this (as well as versioning), they don't support custom setup commands. That and the max 15 minute build time would be blockers.
Comment From: jorisvandenbossche
Also see the relevant discussion at https://github.com/pandas-dev/pandas/issues/17921#issuecomment-759710686 for why it's probably not that easy (security-wise) to use the same server as we push to from the master branch.
Short term, it might be the easiest to move the doc building to an Azure pipeline, as mentioned above by @alimcmaster1 that they support hosting artifacts
Comment From: lithomas1
We use CircleCI now(we got the 400,000 credits/month). I'll look into using scikit-learn's approach if our credit use allows for this.
Comment From: astrojuanlu
I arrive late to this discussion, but Read the Docs would be happy to lift the 15 minute build time for pandas.
The real blocker would be that the docs build process is highly customized, and according to similar past experiences, it would be very hard to make it amenable for RTD. In addition, our story for redirects is not great, and they would have to be recreated using the API from the redirects.csv file.
Still, if folks ever want to have a chat about it, we'll be glad to help.
Comment From: humitos
The real blocker would be that the docs build process is highly customized, and according to similar past experiences, it would be very hard to make it amenable for RTD
I haven't checked deeply this customization, but I wanted to comment here to note that Read the Docs now supports the ability to run custom commands at different steps of the build process by using the config file key build.jobs and that could be useful here. Check out the documentation at https://docs.readthedocs.io/en/stable/config-file/v2.html#build-jobs
Comment From: mroeschke
This has been implemented recently with the /preview command so closing