Release workflow and Netlify docs website

[jayqi]

Testing workflow change:

• As part of testing CI, will build docs and publish a Netlify preview.

New release workflow:

• Triggered by a release created via the GitHub UI
• Builds docs and does a production deploy to Netlify
• Builds package, publishes to Test PyPI and production PyPI

I tested the new release workflow on a fork, and it all seems to work up through Test PyPI rejecting me because I'm trying to push nbautoexport on my personal account and it already exists on the drivendataorg account. https://github.com/jayqi/nbautoexport/runs/904791462?check_suite_focus=true

[codecov[bot]]

Codecov Report

Merging #45 into master will decrease coverage by 0.0%. The diff coverage is n/a.

@@           Coverage Diff            @@
##           master     #45     +/-   ##
========================================
- Coverage    98.1%   98.1%   -0.1%     
========================================
  Files           8       8             
  Lines         381     371     -10     
========================================
- Hits          374     364     -10     
  Misses          7       7             

Impacted Files	Coverage Δ
nbautoexport/export.py	94.9% <0.0%> (-0.7%)	:arrow_down:
nbautoexport/sentinel.py	100.0% <0.0%> (ø)
nbautoexport/nbautoexport.py	98.2% <0.0%> (ø)

[github-actions[bot]]

🚀 Deployed on https://deploy-preview-45--zen-roentgen-1e5a72.netlify.app

[jayqi]

@ejm714 @pjbull @r-b-g-b this is ready for review, I added CI steps to deploy to Netlify.

[ejm714]

@jayqi can you unassign me from review? flagging that I won't have time to get to this and don't want to be a blocker

[jayqi]

(2) Is there any practical different to doing the docs deploy with a GH Action vs. the normal netlify config? Just curious if we should prefer one or the other. I guess not needing a netlify.toml is a pro.

I thought this seemed like it was worth a try for more normal control over the build environment. There's some annoying stuff about the Netlify CI:

• It's hard-coded that if it sees a requirements.txt it will try to pip install it. This fails by default because the default Python is 2.7, so we'd have to add runtime.txt file to set Python 3 and get this to not fail. This is kind of redundant too because we ultimately need to install requirements-dev.txt.
• We end up cramming a bunch of stuff into one build command, e.g., installing requirements-dev.txt before running the command to build the docs

[jayqi]

(1) We'll probably want docs build + deploy to happen more often than just releases until the package gets more mature. During this time as the docs are tweaked, we'll probably want pushes to master to update the docs. Then, at somepoint we can switch over to "stable" and "dev" versions of the docs.

I added another workflow that does the docs and triggers on push to master.