classification
Title: Add deploy preview for docs
Type: Stage: patch review
Components: Documentation Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: BTaskaya, EWDurbin, Mariatta, aeros, docs@python, epicfaace, willingc
Priority: normal Keywords: patch

Created on 2019-08-14 21:14 by epicfaace, last changed 2021-03-22 01:23 by epicfaace.

Pull Requests
URL Status Linked Edit
PR 15288 merged epicfaace, 2019-08-14 21:16
PR 18242 closed EWDurbin, 2020-01-28 21:30
PR 19025 open epicfaace, 2020-03-15 22:54
Messages (7)
msg349752 - (view) Author: Ashwin Ramaswami (epicfaace) * Date: 2019-08-14 21:14
It would be good to preview the cpython documentation on PRs using Netlify.

See https://github.com/python/core-workflow/issues/348
msg350084 - (view) Author: Carol Willing (willingc) * (Python committer) Date: 2019-08-21 13:08
New changeset 87bc3b7a0b0c41ea5da2aa137c4145f437a1c9fd by Carol Willing (Ashwin Ramaswami) in branch 'master':
bpo-37860: Add netlify deploy preview for docs (GH-15288)
https://github.com/python/cpython/commit/87bc3b7a0b0c41ea5da2aa137c4145f437a1c9fd
msg364264 - (view) Author: Ashwin Ramaswami (epicfaace) * Date: 2020-03-15 23:00
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
msg364266 - (view) Author: Ashwin Ramaswami (epicfaace) * Date: 2020-03-15 23:06
GitHub Pages has no limit on "build limits" like Netlify does.

One limitation of this approach, though, is that GitHub Pages sites are limited to 1 GB in size. Each doc build is 50 MB, meaning that we could host at a maximum 20 builds. If we needed to, we could resolve this by doing one (or multiple) of the following:
- check with GitHub to see if they will increase the limit for this case
- only build PRs that have been tagged "documentation"
- add a workflow to automatically remove deploy previews after a certain amount of time has passed or after a PR has been merged
- don't deploy on GitHub Pages, but use something like https://surge.sh/, which apparently doesn't have a hard limit on size of a static site
msg364271 - (view) Author: Kyle Stanley (aeros) * (Python committer) Date: 2020-03-15 23:35
> 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.
msg368201 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2020-05-05 19:52
> 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.
msg389269 - (view) Author: Ashwin Ramaswami (epicfaace) * Date: 2021-03-22 01:21
I realized there's another alternative which is probably simpler. We can use Netlify to host the deploy previews, but we can use GitHub Actions to build the documentation. This way, we won't run into the build time limits for Netlify, and we can still use Netlify to host deploy previews.

We can use this GitHub Actions action: https://github.com/marketplace/actions/netlify-actions, and just add it as an additional step to our existing doc GitHub Actions workflow (https://github.com/python/cpython/blob/master/.github/workflows/doc.yml).

What do you think about this approach?
History
Date User Action Args
2021-03-22 01:23:26epicfaacesetnosy: + EWDurbin
2021-03-22 01:21:45epicfaacesetmessages: + msg389269
2020-05-05 19:52:50BTaskayasetmessages: + msg368201
2020-03-16 18:36:14brett.cannonsetnosy: - brett.cannon
2020-03-16 02:38:12BTaskayasetnosy: + BTaskaya
2020-03-16 02:11:52epicfaacesettitle: Add netlify deploy preview for docs -> Add deploy preview for docs
2020-03-15 23:35:31aerossetnosy: + aeros
messages: + msg364271
2020-03-15 23:06:43epicfaacesetmessages: + msg364266
2020-03-15 23:00:23epicfaacesetmessages: + msg364264
2020-03-15 22:54:21epicfaacesetpull_requests: + pull_request18373
2020-01-28 21:30:44EWDurbinsetpull_requests: + pull_request17622
2019-08-21 13:08:50willingcsetnosy: + willingc
messages: + msg350084
2019-08-15 16:22:22brett.cannonsetnosy: + brett.cannon
2019-08-14 21:16:18epicfaacesetkeywords: + patch
stage: patch review
pull_requests: + pull_request15012
2019-08-14 21:15:03epicfaacesetnosy: + Mariatta
2019-08-14 21:14:46epicfaacecreate