The history project collects and publishes information on past shows, committees and other goings-on at The Nottingham New Theatre the only student run theatre in England.
We use a static site generator (Jekyll) among other tools to turn the data and website source hosted here into the website published at history.newtheatre.org.uk.
This project is run by a group from the New Theatre's Alumni Network.
There are 2 common ways to use this repository:
You can do this primarily in one of two ways: using the GitHub web interface (good for very minor tweaks); or by editing the files on your computer.
The site's Contributor's Guide has all the information you need for this.
You'll be able to see the changes you make when you open a Pull Request with our Deploy Previews. If you'd like to see your changes locally, keep scrolling.
If you're editing templates, plugins, and so on, you likely want to be able to view your changes and test them locally before you push.
The first thing you'll need to do is clone (download) the repo onto your computer. You can do this a variety of ways, the easiest are either downloading the zip or using the following command, providing you have Git installed:
git clone https://github.com/newtheatre/history-project.git
You can then either use Docker, or build the site yourself to see your changes.
To save your changes back to GitHub, you will need to use a Git client, which you can do from the command line, or download and use a graphical one. We recommend GitHub Desktop or GitKraken.
Docker is a cross platform software container platform. Following these instructions will allow you to build and view the site on your local machine in an environment as close to the production system as possible.
cd history-project
to change into the project directory../run_dev.sh
(Windows users: wsl run_dev.sh
)Once everything has finished running, you should see the site at http://localhost:8000
. Hit
ctrl+c to stop the server. If using 'Docker Toolbox' and localhost
doesn't work, you can find the IP address of the virtual machine by running echo " $(docker-machine ip default)"
By default ./run_dev.sh
uses the parameters start
install
build
test
serve
in that order.
start
builds the docker container, and starts it running in the backgroundinstall
installs all necessary dependencies for the sitebuild
builds the jekyll sitetest
runs the test suiteserve
runs a server so you can view the site locallystop
halts and destroys the docker container. You will need to run start
and install
again after running thisYou can add/remove steps to ./run_dev
as needed. For example, there is no need to run start
or install
every time you want to build the site.
Environment variables (such as the Smugmug API key) can be changed by modifying the ENV
lines in the Dockerfile (and then running start
again).
To get the site running locally you will need:
We'll get that sorted, then install the project.
We don't recommend doing it this way on vanilla Windows, though if you use the WSL you can follow the Ubuntu instructions.
bundle config --local path vendor/bundle
to install the Ruby packages to within the repository folder. Helpful if you are working on multiple different projects.bundle install
to install all the Ruby dependencies the project needs to build.npm install
to install all the Node dependencies the project needs to build.
npm link gulp-v3
to get our version of gulp to behave.bower install
to install all the frontend dependencies the project needs to build.gulp build
to build the site to _site.gulp debug
does the same but skips minification and enables Jekyll's incremental builds.gulp server
to serve the site using the built in webserver. Changes to Sass & Coffee files will trigger an automatic frontend rebuild and reload. Content (Jekyll) changes will not, this is because Jekyll takes a considerable time to run.βΉοΈ If
gulp
commands don't work ('build' is not in your gulpfile
), try usingnode_modules/.bin/gulp
(egnode_modules/.bin/gulp build
) instead.
To get more verbose output from Jekyll, run export JEKYLL_LOG_LEVEL=debug
before building.
After building the site you can run the test suite with gulp test
. Currently we test for bad links, valid image tags, script references and the validity of site JSON feeds.
Bear in mind you may want to disable htmltest's external link checking as this may take some time on a consumer internet connection.
You may also test the syntax of YAML front-matter via gulp yamllint
.
Branches pushed to the GitHub repo are have preview builds deployed on Netlify, you can find links to the most recent ones here: https://app.netlify.com/sites/history-project-dev/deploys.
All photographs, image assets, and videos under 20 minutes in length are stored using the theatre's SmugMug.
Other binary assets are stored under assets/
using Git LFS. This separates these large files from the main repository. If you do not have LFS set up on your machine please do not attempt to commit assets as this would bloat the repository.
This project as a whole isn't particularly helpful for other organizations, what we're doing here can be described as coding in the open, rather than building an open source project. That said parts of the project may be of interest or use to others. This repository is a mix of source and content, as such there are two licences that apply.