Documentation continuous integration and deployment

[davenquinn]

Updating Sparrow's documentation is currently tedious, which partially explains why it happens infrequently. Changes must be made and verified locally, pushed to Github, and finally manually built on the server. This manual deployment step means that I am the only developer empowered to make even minor updates. As we transition to a wider set of contributors, a better process is needed to ensure changes can be made by anyone.

CI/CD provides a means to automate much of the deployment process: changes will be proposed on GitHub, automatically tested, and deployed once they are accepted and merged to master. This should allow others in the team to make changes to the website without server access. This will be especially important for ongoing updates, and for community sourcing of narrative text such as embargo policy, etc. Building CI/CD for documentation will build knowledge needed to work on improving the upgrade process Sparrow itself (see #14 and #15).

Steps to CI/CD for documentation

• [x] Make sure the entire documentation can be built with a single command
• [x] Add basic tests to ensure that documentation website properly builds
• [x] Wire up with a continuous integration service to build and test. Possible providers include Travis CI or UW Madison's DoIT GitLab service. The latter might be preferable due to its network proximity to our servers and first-party nature, but it may be more difficult to configure and use.
• [x] Pipe output of CI (a collection of Docker containers) to server and automate deployment.

Success metric

Any authorized contributor can make a change (either locally or directly in the GitHub editor), and it will be propagated automatically into the "live" documentation website.

[davenquinn]

We are now using GitHub Actions CI to build the documentation, but it misses some parts (e.g. Python API docs) and deployment is not fully solved yet.