============= Build Process ============= The build process for our site is designed to be as easy, and automated, as possible. The webpage rebuilds nightly (to sync our publication list with Zotero), and also after every closed pull request to ``master``. Normal users of the site should not need to understand or use these features, but we want to document them for whoever is in charge of site management. ^^^^^^^^ Overview ^^^^^^^^ The site's build process is managed through `GitHub Actions `_ which has certain triggers for building both the main page and the dev page (which can preview potential changes to the site). We build our site through `Jekyll `_, a static site generator written in Ruby. If you'd prefer, you can always build the site locally using the instructions provided through Jekyll. The build process happens locally on our server, which is managed through Stanford. Specifically, whenever the page is built, the server: #. Pulls down the most recent copy of :code:`master` from our repo. #. Pulls down the most recent bibliography from Zotero, along with any new PDF files attached to publications. #. Builds the site with Jekyll, which generates all HTML, CSS, etc. files needed to serve the website. #. Copies these files to :code:`/var/www/` on the server, which are then served by Apache. ^^^^^ Notes ^^^^^ * You can edit the automatic build frequency, or really any part of the build process, by editing the associated GitHub action. Thus, permissions to do this should be restricted only to members of the web team. * The actions include a webhook which posts a notification to ``#website`` on our Slack whenever a PR build is triggered -- this helps keep the web team up-to-date about open PRs, etc. It should also post an alert if a build fails for any reason.