One of the challenges with deploying static sites is that there's nothing
tracking any sort of site state, including when new content is published. This
post presents a technique to identify newly published content on an Eleventy
site and sending various notifications with content-specific data.
Part 1 covered
identifying the new posts and collecting post-specific data. Part 2 covers
posting a status to Mastodon, posting a status to Bluesky, and sending an
IndexNow notification for the new page.
One of the challenges with deploying static sites is that there's nothing
tracking any sort of site state, including when new content is published. This
post presents a technique to identify newly published content on an Eleventy
site and sending various notifications with content-specific data. Part 1 covers
identifying the new posts and collecting post-specific data.
This post details the GitLab CI pipeline used for this blog, which is built with
Eleventy. It's based on a collection of GitLab CI
templates that have evolved over several years for my published NPM packages
with a collection of end-to-end tests used for web applications and a few unique
jobs added specifically for Eleventy and Nunjucks templates. It's meant as an
illustration of a reasonably comprehensive CI pipeline for an Eleventy static
site, maximizing the level of automated testing, leveraging built-in GitLab
capabilities where practical, and optimizing parallelization and pipeline speed.
GitLab Pages
provide an easy means of deploying a site hosted on GitLab, but GitLab does not
provide support for creating Review Apps for a Pages site. This post outlines a
reusable technique to work around that and setup Review Apps with
Eleventy to enable creation of a unique, browsable
instance of a site with the changes in a merge request.
Aaron Goldenthal