layout: page
title: VTSS Group Website Readme
This readme file is published in its fully rendered form on the website.
The source code for this site is hosted on the DoC GitLab server, you should have access to edit it if a member of the resource-reasoning group.
DO NOT EDIT THE SOURCE CODE IN /vol/rr/www
, IT IS ALL REPLACED EACH TIME THE SITE IS REBUILT FROM VERSION CONTROL
Managing Content
Publications
Please see the dedicated publications repository for instructions on how to add new publications to the website.
Technical Detail
This website is built using the Jekyll website framework. Pages can be written using Markdown (preferred) or HTML. Files should be named with the extension they're writen in (.md, .markdown, .html, ...), they'll be compiled to .html versions of the file on publication. (Unless otherwise specified with the 'permalink' property of the page).
Pages to be interpreted by the Jekyll framework should be started with a YAML variable block. The variables here can be used to change properties of the page. For further details, see the Jekyll documentation. For example, to set the page title and it's URL:
---
title: Page Name
permalink: /my-custom-page-path/
---
Variables that templates currently take into account are:
-
title
, sets the page title -
menu
, (default: false) places the page into the website's navigation menu -
menu_order
, decides the order of menu -
parent_menu
, creates a parent menu with a dropdown box including the current page. Pages with the same parent menu are put in the same box. Please also ensures the existence of parent_menu and its value, and menu_order are consistent. -
sub_menu_order
, decides the order of menu in corresponding dropdown box. -
project_id
, links the page to a project. -
project
, (please only use this for person, i.e. file under the directory of _people), links a person to a project. -
firstname, lastname, position, webpage, email, github
, describes a person.
The main content of the page should then follow.
Any other files present in the directory structure (except for those prefixed with _
, .
, or explicitly excluded in _config.yml
) will be published unchanged to the website.
For the detail of adding publication, please refer to the README file in publication directory.
Jekyll Scholar Configuration Detail
We desire the output URL structure to be:
-
/publications/
-
index.html
- a page listing the entire bibliography -
publications.bib
- the raw bibtex file, directly from the source -
Key.html
- details page generated for each publication -
Key.*
- Any files associated with each publication, copied directly from the source
-
In the scholar
section of the configuration file, configuration options we've used are:
-
source
: Directory in which our bibtex files are to be found (publications
) -
details_dir
: Directory to outputKey.html
files for each publication (publications
), rendered using the layout defined in thedetails_layout
option. -
details_link
: We override the default here, as we generate our own HTML to render this link in ourbibliography_template
. -
repository
: Location of files associated with publications (publications
) (the same directory is used for both input and output: it is handled as usual by jekyll)
The template used to generate individual publication pages is here. The part of interest is the Source Materials section. We iterate through a predefined list of file types and output a link (using icon and text from the file type list) to the file in the repository if it exists.
Finally, in order to generate the complete biography page, we use a page in the site's root just
outputting a {% bibliography %}
as normal (which renders each entry using the layout defined by the scholar
bibliography_template
option). By using a permalink
jekyll option we place the rendered bibliography into the
/publications/
output directory as index.html
.
Testing and Deployment
The DoC GitLab instance is configured (using .gitlab-ci.yml) to build, test and deploy the website on tests passing. The tests run are to check that the build works (no critical syntax errors in templates), and that internal page links are consistent.
An additional check that external links are still live is also run, but this test is permitted to fail without blocking the deployment.
The site should be deployed automatically by GitLab CI. To deploy the site manually from your own machine, run the .deploy.sh
script. This will use rsync
to synchronise the contents of the _site
directory with the webserver via SSH. Default deployment parameters:
- DOC_DEPLOY_USER: the default username used by SSH to connect, usually the username on your local machine
- DOC_DEPLOY_SERVER:
shell1.doc.ic.ac.uk
- DOC_DEPLOY_PATH:
/vol/rr/www
To override these parameters, set shell variables, eg:DOC_DEPLOY_USER=me ./.deploy.sh
The site is deployed to /vol/rr/www
automatically on successful build using the .deploy.sh
script.
The contents of the DOC_DEPLOY_KEY
CI environment variable are used
as the private key used to authenticate with the server. This key is currently configured to give locked-down rsync access to the
/vol/rr/www
using pg
's user account. For further details for how this is achieved, see this
howto. Note: when deploying to a locked-down
rsync account, the DOC_DEPLOY_PATH should be set to a path relative to the lockdown path -- use .
if in doubt. You
won't need to set this if you're deploying from your own user account.
Locally Building and Testing
If you wish to test the site locally, ensure you have ruby installed, and then initially run:
gem install bundler
bundle install
bundle exec rake init
And to start a local webserver that remakes files whenever changed:
bundle exec rake serve
You can test for dead links and html errors using:
bundle exec rake test