Change by Ashwin Ramaswami : ---------- nosy: +Mariatta _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Change by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Change by Ernest W. Durbin III : ---------- pull_requests: +17622 pull_request: https://github.com/python/cpython/pull/18242 _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Ashwin Ramaswami added the comment: Given Ernest's comment in https://github.com/python/cpython/pull/15288#issuecomment-579476340 about the limitations of Netlify (1000 build minutes per month), it doesn't seem like Netlify will be a viable alternative. Instead, I've added a PR (https://github.com/python/cpython/pull/19025) that takes an alternative approach. It uses GitHub Actions to deploy the docs to the gh-pages branch, then adds a comment to the PR with a link to the deploy preview. The way this works is that the gh-pages branch has subfolders with the SHA of each commit, and each deploy preview is deployed to each subfolder. I've enabled this on my fork of cpython -- here's an example PR on my fork: https://github.com/epicfaace/cpython/pull/7 ---------- _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Kyle Stanley added the comment:

only build PRs that have been tagged "documentation"

My preference would be to have a "preview-with-netlify" label that could be manually added to use the netlify preview on a case-by-case basis. There are a substantial number of trivial PRs (such as typo fixes and similar minor changes) that are automatically labelled as "documentation" which wouldn't particularly benefit from the netlify preview and would needlessly occupy part of the limit. Personally, I feel that it most largely benefits more significant documentation changes that involve modification of existing markup or the addition of new markup, rather than all documentation PRs. So a manually added label to trigger it makes the most sense to me. This would be very similar to the recently added "test-with-buildbots" label. ---------- nosy: +aeros _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Change by Batuhan Taskaya : ---------- nosy: +BTaskaya _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Batuhan Taskaya added the comment:

Personally, I feel that it most largely benefits more significant documentation changes that involve modification of existing markup or the addition of new markup, rather than all documentation PRs. So a manually added label to trigger it makes the most sense to me. This would be very similar to the recently added "test-with-buildbots" label.

+1, It would be so much useful in cases like GH 19928. ---------- _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________

Change by Ashwin Ramaswami : ---------- nosy: +EWDurbin _______________________________________ Python tracker https://bugs.python.org/issue37860 _______________________________________