Build only what changed
From #1265 (comment 48411304):
Given that the blog only takes a minute or so to rebuild, perhaps what we can do in the short-term is to do what @rspeicher suggests:
As a first step maybe we want to limit this specifically to files in
source/posts/
, so that blog posts at least build quickly. But there are edge cases there as well. I have no idea how this would interact with the generated monthly release posts, for example.
I think we can create a rule to rebuild only the blog if we see only changes to the following files:
-
source/posts/
-
data/release_posts
-
etc.
Otherwise we default to doing a full rebuild.
The downside is that we'd have to cache the public/
directory, which looks like it's 500 MB at the moment.
Original description
I recently migrated Conversational Development from Middleman to Jekyll because:
- Jekyll has incremental builds which when incorporated into CI allows the build times to be significantly reduced as the site grows.
- Jekyll is the most widely supported and well known static site generator and blogging platform (it even runs on Windows with no hassle) allowing others to easily contribute.
Feedback on the migration
- The migration was quick (couple of hours) and easy for a small site like conversationaldevelopment.com. Considering the size of www-gitlab-com I suspect it will take at least a week to migrate.
- I chose to migrate the haml templates to erb, even though there are plugins to use haml in Jekyll, as I wanted to depend on less 3rd party gems. Choosing to this increased the work needed to migrate the site. I used a gem to convert haml to erb but still needed to manually edit templates to output variables different in each SSG. -conversationaldevelopment-com has nothing out of the ordinary in the build process where www-gitlab-com fetches content from other repos and generates PDFs.
Next steps for migrating www-gitlab-com to Jekyll
I suggest someone spends 1-2 hours gathering further non-standard steps in the www-gitlab-com build process and investigate possible solutions for the migration.
@JobV what do you propose the next steps should be?