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.
There are some cases where the expected outcome of a CI job script is failure.
One prominent use case is the testing of tools and container images that are
intended for CI-based analyses. This post details techniques for GitLab CI
scripts that will allow the job to pass when the script fails to accurately
reflect the expected result.
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.
Gitlab Releaser v5.0.0 was released today with several noteworthy
changes, including failing if an empty release description is pulled from
the CHANGELOG and a new CLI option to specify the CHANGELOG path.
Google Chrome's Lighthouse tool is a great resource in the browser and has
become the standard for basic performance and best-practice metrics on
websites. While useful in the browser, a good continuous integration (CI)
pipeline includes all the testing practical to identify any issues as early as
possible. To that end, this post details how to run Lighthouse via the CLI
in GitLab CI and collect a GitLab metrics report so any changes will be
reported in merge requests.
Aaron Goldenthal