Skip to content

ci: build Jekyll on every PR/push, not only on deploy to main - #389

Merged
msgwing merged 3 commits into
mainfrom
ci/build-jekyll-on-pull-requests
Aug 30, 2026
Merged

ci: build Jekyll on every PR/push, not only on deploy to main#389
msgwing merged 3 commits into
mainfrom
ci/build-jekyll-on-pull-requests

Conversation

@msgwing

@msgwing msgwing commented Aug 30, 2026

Copy link
Copy Markdown
Owner

Summary

Closes #367. pages-deploy.yml only builds Jekyll on push to main, so a broken Liquid template in a PR passes every other check and only breaks after it's already on production - exactly what was verified by hand (not by a gate) during #366's review. New jekyll-build job in lint.yml runs the same build on every push/PR, without the deploy steps.

Test plan

  • python .github/check-workflows.py - clean
  • This PR's own CI run is the real test (no Ruby available locally) - the new jekyll-build job must go green here

…shing

Found today while building the VS Code extension: npm still serves
1.2.1 (published 2026-08-22 17:58), but #300 (2026-08-26) exported
explain()/explainJson() as part of the public API and added a 25-test
suite - four days of real functionality nobody running `npx
zerosmtp-check` from npm actually has yet. The VS Code extension had to
depend on this package via file:../zerosmtp-check specifically because
of this gap.

Version bump only - .github/workflows/publish-npm.yml is manual by its
own design ("publishing is the owner's decision", a version is
permanent once published). Filing a do-akceptacji issue with the exact
dispatch instructions rather than triggering it myself.
Gap closed today (#386, #387): zerosmtp-check@1.3.0 is now on npm with
explain()/explainJson() actually exported. Switched the dependency from
file:../zerosmtp-check to ^1.3.0 and verified end to end - reinstalled
from a clean node_modules, confirmed the resolved package.json really
is 1.3.0, ran the extension's own test suite against it (9/9), and
ran the exact dynamic import() the extension code uses
(zerosmtp-check/index.js) directly to confirm explain() is callable
from the real published package, not just present by version number.
Found during review of #366: pages-deploy.yml only builds Jekyll on
push to main, so a broken Liquid template (unclosed {% if %}/{% elsif
%}, a bad include) in a PR passes every other check here and only
breaks once already on production. That PR was verified by hand
(grepping the if/elsif/endif chain) rather than by a gate - which
worked once but doesn't scale to every future change in
docs/_layouts/ or docs/_config.yml. Closes #367.

New job runs the same build pages-deploy.yml runs (same Ruby version,
same --config flags, same fetch-depth: 0 for jekyll-last-modified-at),
minus the deploy steps. No Ruby available locally to test this
directly - the real test is this PR's own CI run.
@github-actions github-actions Bot added the ci label Aug 30, 2026
@msgwing
msgwing enabled auto-merge (squash) August 30, 2026 21:56
@msgwing
msgwing merged commit e783b19 into main Aug 30, 2026
36 checks passed
@msgwing
msgwing deleted the ci/build-jekyll-on-pull-requests branch August 30, 2026 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ci: brak sprawdzenia buildu Jekyll na pull requestach

1 participant