Skip to content
This repository has been archived by the owner on Mar 20, 2021. It is now read-only.

Evaluate transition away from Jekyll #94

Open
lenucksi opened this issue Feb 19, 2020 · 1 comment
Open

Evaluate transition away from Jekyll #94

lenucksi opened this issue Feb 19, 2020 · 1 comment
Labels
website Things revolving around our website

Comments

@lenucksi
Copy link
Member

Various people repeatedly have had trouble creating a working development environment for our Jekyll-based site, one of them being @dellagustin-sap in #91. Other than that there's the odd security notice from time to time to handle.

A few other factors exist that might want to have us consider a different static-site generator.
Here's where I brought this up first: InnerSourceCommons/innersourcecommons.org#91 (comment)

And here's the content from that post:
Thanks for approaching this @dellagustin-sap! I've found myself in the "appreciating all the Jekyll things" phase repeatedly only to be overwhelmed by a case a radical pragmatism every time - "screw non-system-wide installation of Jekyll, let's get this done!" ;).
As for the desired features you mentioned initially - I'm fully on board with wanting to have them and Docker looks like a way to go here.

However I'd like to play a bit of the "advocatus diaboli" here in the hopes of saving quite a bit of effort and maintenance in the long run for a 1 or 2 afternoon conversion effort.
I assume the following as a current and desired position:

  • We've got a website that is not excessively complex, all based on a static site generator, Jekyll currently

  • We need to be able to handle Markdown and ASCIIDoc (the learning path content)

  • We want our site to be tested and deployed using CI+CD to GitHub Pages (or possibly somewhere else later) with minimal interaction and need to deal with security updates and maintenance

  • We want our site to be easily editable, previewable, self refreshing, etc locally

  • Currently we use Jekyll as our static site generator, Jekyll does indeed work and is popular.

    • However we face the need for manual security updates and creating a local development environment is quite the effort (see this thread)
    • Jekyll offers quite a bit of plugins, which makes it rather flexible
    • Currently we're testing and deploying using a custom Travis CI YAML and script.
    • There are pre-built GitHub Actions for this too.
  • There is Hugo, another static site generator written in Go and hence offering the usual "single binary" approach.

    • It accepts Markdown and with the usual conversion extensions, just as Jekyll, ASCIIDoc too
    • It's really fast and offers instant rebuilt on file system change
    • Local setup is trivial (MacOS brew, Linux Package Managers or brew, Windows Chocolatey or manual download) and just works, as all you do is install the usual single binary.
    • CI builds can be done using Travis or readymade GitHub Actions.
    • There are conversion scripts to convert the metadata and structure from Jekyll to Hugo

I successfully run my website on Hugo as do quite a lot of other people.
Would you be open to consider the idea of attempting a Hugo conversion for the website and migration to Hugo GitHub Actions instead of the Docker route?
I could also help a bit with this as I already successfully run Hugo.

@lenucksi lenucksi added the website Things revolving around our website label Feb 19, 2020
@rrrutledge
Copy link
Collaborator

It doesn't bother me if someone wanted to convert it, but I haven't experienced said difficulties with Jekyll so it doesn't bother me to stay, either.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
website Things revolving around our website
Projects
None yet
Development

No branches or pull requests

2 participants