Nokogiri GitHub Actions Cache Maintenance for Parser Pipelines

Nokogiri is the Ruby XML and HTML parser that still sits inside a lot of web scraping, content cleanup, and ETL jobs. This week was a quiet build maintenance pass, but it is worth a look because parser libraries with native code depend on broad, repeatable CI more than most application gems.

Only one commit landed in the seven day window: a Dependabot update that touched three workflow files and changed 18 inserted and 19 deleted lines. The code paths that parse XML, HTML4, HTML5, XPath, CSS selectors, XSLT, or schema validation did not move. For users, that means no new API surface, no parser mode change, and no migration work.

That limit is the point. Nokogiri wraps native parsers and ships across Ruby versions, operating systems, system libraries, and vendored library modes. A small workflow update can matter because it protects the test machinery that catches build drift before a release reaches a scraper fleet.

The largest part of the change is in .github/workflows/ci.yml. actions/cache now points at the v6.1.0 commit in the Linux, macOS, Windows, TruffleRuby, memory, memcheck, generic package, and CRuby package jobs. The workflow keeps the existing comments that document why the cache is branch isolated and why fork pull requests cannot write the base branch cache.

For data pipelines that parse hostile or messy HTML, this is not an academic detail. The cache stores Nokogiri ports and tarball archives, and those jobs cover builds with bundled and system libraries. If cache rules drift, tests can pass in one path and fail in another. Keeping the action current while preserving the zizmor ignore rationale makes the exception visible instead of implicit.

The same cache update also lands in .github/workflows/upstream.yml, where jobs compile against current libxml2 and libxslt sources, Ruby head, TruffleRuby head, and html5lib tests. That file is the early warning path for parser ecosystem movement.

In the GitHub Actions audit job, actionlint moves from v1.7.11 to v1.7.12, and zizmor moves from v0.5.2 to v0.5.7. Both are pinned by commit SHA, not just a floating version tag. That matches the rest of the workflow style, where actions/checkout, Ruby setup actions, and cache actions are also pinned.

Nokogiri already runs the audit job before the wider matrix, with basic depending on both RuboCop and the workflow audit. That ordering is useful. A syntax issue or a bad Actions pattern should fail before the native build matrix burns runner time across Linux, macOS, Windows, JRuby, TruffleRuby, and system library combinations.

This is also the part of the activity that has the clearest supply chain reading. It does not patch Nokogiri itself. It does keep the tools that inspect the pipeline close to current, which is where a parser project with release artifacts should spend a little boring effort.

The smaller functional cleanup is in .github/workflows/downstream.yml. That workflow compiles Nokogiri, clones downstream projects such as Loofah, Rails HTML Sanitizer, Sanitize, Ruby SAML, Mechanize, and others, then replaces their Nokogiri dependency with the local checkout. The update removes a separate gem install bundler -v ">= 2.3.22" step before bundle install.

That matters because downstream tests are supposed to expose compatibility issues, not add their own version policy unless the project really needs it. The workflow still removes bundler from the downstream bundle where needed, still strips gemspec Bundler development dependencies if they are present, and still adds the local Nokogiri path before install. The cleanup narrows the moving parts.

For ETL teams, this is the closest thing to an application signal in the commit. If you depend on Nokogiri through a higher level sanitizer, crawler, or document processor, downstream test coverage is where regressions show up before they reach your lockfile. The commit keeps that coverage but makes one setup step less special.

First, do not read this activity as a new Nokogiri release or a parser fix. The staged window has one build dependency commit and no library code changes. Any production pin change should still follow the normal gem release notes, not this workflow diff.

Second, the broad cache replacement is still worth tracking if your own scraper or ETL gem has a native build matrix. Copying the version bump is less important than copying the discipline: pinned actions, explicit cache rationale, and branch scoped keys.

Third, watch the upstream workflow more than the cache action name. Jobs that compile against libxml2 and libxslt source heads tell you where future breakage may come from. For HTML and XML pipelines, that is usually more actionable than a weekly dependency bump.