ci: build Jekyll on every PR/push, not only on deploy to main - #389
Merged
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #367.
pages-deploy.ymlonly builds Jekyll on push tomain, 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. Newjekyll-buildjob inlint.ymlruns the same build on every push/PR, without the deploy steps.Test plan
python .github/check-workflows.py- cleanjekyll-buildjob must go green here