Commit 74a1209e authored by Jamie Tanna's avatar Jamie Tanna
Browse files

Merge branch 'article/reveal-hugo' into 'master'

Document move to reveal-hugo for

See merge request !249
parents d0659b72 07f65e66
Pipeline #47904115 passed with stages
in 10 minutes and 9 seconds
title: "Moving to reveal-hugo"
description: "Migrating my custom Reveal.JS setup to using reveal-hugo."
- announcement
- revealjs
- hugo
license_code: Apache-2.0
license_prose: CC-BY-NC-SA-4.0
date: 2019-02-17
slug: "moving-talks-to-reveal-hugo"
As part of the [Merge Request _Convert Reveal.JS slides to reveal-hugo_](, []( is now built using [Josh Dzielak]('s project [reveal-hugo](
This makes the setup of the project much more simple, and means I now have a well tried-and-tested structure for creating [Reveal.JS]( presentations.
As mentioned in the merge request description:
> Instead of using a homegrown, overly engineered setup for my slides, it's easier to re-use existing setup such as reveal-hugo, especially as I now use Hugo for
My original setup was creating [revealjs-starter](/projects/revealjs-starter/) which used Ruby's ERubis templating language with a custom YAML config file and a Rakefile to tie together the build process, which was then served with Rackup. Most of these would be symlinks from the starter project so there wouldn't need to be as much duplication, but it wasn't really the best practice for a lot of repetition.
This was partly as Ruby is my new favorite scripting language, but also as I didn't want to use something like [generator-reveal]( as it was a bit Node-heavy and I wasn't a fan.
When I got used to my horrible Ruby setup, it was pretty straightforward to work with, but after months of not touching a presentation it was not as fun coming back to the repo, as I would have to re-learn how it all works.
As part of the move to reveal-hugo, it also meant that I needed to script the conversion of the existing setup to reveal-hugo's expected setup. And this migration needing quite a lot of scripting also showed just how bad the original setup was.
This also means I have the blazing fast speed of Hugo, as well as making it much easier to manage GitLab CI setup:
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9a3c41be7..319d22413 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,23 +2,22 @@ variables:
- deploy
stage: deploy
- - "./.ci/ chef-infrastructure-as-cake"
- - "./.ci/ came-for-the-campus-stayed-for-the-community"
- - "./.ci/ overengineering-personal-website"
- - "./.ci/ free-open-source-software"
- - "mkdir public"
- - "touch public/index.html"
- - "./.ci/ chef-infrastructure-as-cake 'Chef: Infrastructure as Cake'"
- - "./.ci/ came-for-the-campus-stayed-for-the-community 'Came for the Campus, Stayed for the Community'"
- - "./.ci/ overengineering-personal-website 'Overengineering Your Personal Website - How I Learn Things Best'"
- - "./.ci/ free-open-source-software 'Free and Open Source Software'"
- - apk add --update curl
+ - hugo -d public
- curl -LO
- tar xvf netlifyctl-linux-amd64-0.4.0.tar.gz
- ./netlifyctl deploy -s b758cf8f-9eeb-4770-ba63-ce7defafe8f6 -P public -A $NETLIFY_ACCESS_TOKEN
Which wasn't very scalable, as each new presentation requires a build step _and_ a deploy step.
Where I previously had these two files to orchestrate the build steps `.ci/`:
#!/usr/bin/env sh
cd "$1"
# Install front-end dependencies
npm install
./node_modules/bower/bin/bower --allow-root install
# install rake+erubis
bundle install --path vendor/bundle
bundle exec rake
Which is then "deployed" by `.ci/` into the right folder, and adding a link to the `index.html`:
#!/usr/bin/env sh
# `-L` to resolve symlinks and output the files as they are
cp -LR "$1/out" "public/$1"
mv "public/$1/slides.html" "public/$1/index.html"
echo "<a href='$1/'>$2</a>" >> public/index.html
reveal-hugo also has an easier ability to customize the setup for Reveal.JS itself on a per-presentation basis which is much easier than the existing setup I had which wasn't as flexible.
I'm really enjoying the developer experience of reveal-hugo in comparison to my existing setup!
......@@ -9,6 +9,8 @@ tech_stack:
- revealjs
project_status: ongoing
**Note**: This project is now archived and no longer required as I'm now using [reveal-hugo](
When I decided to move from creating slides for talks using LaTeX Beamer to Reveal.js, after I had written a couple of slides in Reveal.js, I found that there was a large amount of boilerplate that wouldn't change.
This project simply makes it possible to get an (opinionated) setup for Reveal.js by running i.e. `rake 'init[rake_ruby_builds_slides, Rake and Ruby builds]'`. This will configure the directory structure and install dependencies, making it possible to get up and running as quickly as possible.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment