🪲 [Fix]: Documentation site publishes again on every push and scheduled run - #107
🪲 [Fix]: Documentation site publishes again on every push and scheduled run#107Marius Storhaug (MariusStorhaug) wants to merge 1 commit into
Conversation
…nt dependency Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
|
Verified on the real workflow, not just by reasoning.
That red run is expected and is not a defect in this change. The The run is attached to this branch's head commit, so it may surface as a red This closes the last acceptance criterion that could not be checked before merge. The remaining post-merge confirmation is unchanged: a new |
There was a problem hiding this comment.
Pull request overview
Restores GitHub Pages publishing for the documentation site by fixing the workflow job dependency graph so the Publish job is no longer skipped when Lint is skipped (non-PR events).
Changes:
- Remove
lintfrompublish.needs, leavingpublishdependent only onbuild. - Add an inline comment documenting why
lintmust not be a dependency (mutually exclusive conditions + implicitsuccess()behavior).
The documentation site at psmodule.io/docs publishes again. Since 2026-07-19 every merge to
mainand every scheduled run reported a greenDocscheck while quietly deploying nothing, so the published site had been frozen on the 2026-07-18 build for two weeks. Anything merged in that window — including the Repository Standard page — was invisible to readers.Fixed: merged documentation reaches the site again
A merge to
mainthat touches the documentation sources now deploys the built site, and the scheduled run redeploys it so the generated module catalog stays current. Nothing else about the pipeline changes: a run whose build fails or is cancelled still deploys nothing, and a pull request still only lints and builds without ever touching the live site.No action is needed from readers or contributors. The first merge after this lands republishes the site, and pages merged during the frozen window appear at that point.
Technical details
Verified root cause. In GitHub Actions a job whose
needslist contains a skipped job is itself skipped, unless its ownifuses a status function such asalways(),!cancelled(), or an explicitneeds.<job>.resultcheck. A plainif:expression is implicitly wrapped insuccess(), andsuccess()is false when an upstream job was skipped.publishdeclaredneeds: [build, lint]with a plainif: github.event_name != 'pull_request', whilelintdeclaresif: github.event_name == 'pull_request'. On every event that can reachpublish,lintis skipped, sopublishwas skipped too — while the run as a whole still concludedsuccess, because a skipped job is not a failed job.Evidence, gathered before the change:
Introduced by #74 (merged 2026-07-19), which added the
scheduletrigger and restrictedlinttopull_request. The newest deployment predates it by one day.Why remove the edge rather than neutralize it.
lintruns only onpull_request;publishruns only when the event is notpull_request. The two are mutually exclusive by construction, so thepublish→lintdependency can never carry a signal in either direction. Keeping it and adding!cancelled() && needs.build.result == 'success'would work, but it preserves an edge that reads as a lint gate while gating nothing, and it replaces the implicitsuccess()overbuildwith a hand-maintained result comparison that has to be kept correct by hand.needs: [build]with a plainif:keeps the implicitsuccess(), so a failed or cancelled build still blocks deployment with no explicit check. A comment on the job records whylintis absent, so it is not reinstated.Acceptance criteria against the resulting condition.
buildlintpublishpushtomainscheduleworkflow_dispatchbuildfails or is cancelledsuccess()pull_requestgithub.event_name != 'pull_request'Verification. The failure is a workflow-graph condition and is not reachable from this repository's build, so there is no automated regression test to add. The equivalent repeatable verification recorded on #106 is: after merge, confirm a new
github-pagesdeployment exists whoseshamatches the merge commit, and thatModules/Repository-Standard/resolves.Standards and framework alignment.
.github/workflows/Docs.ymlpermissions, secrets handling: all unchanged and already compliantPSModule/docshas no framework docs for its own site pipeline)needs, which is why this class of bug was reachable — raised as MSXOrg/docs#149Issue convergence sweep. Scope: open issues in
PSModule/docsmentioning the site build, theDocsworkflow, or publishing. #106 is the only issue this diff satisfies. #103 and #104 concern page content and are untouched here. TheRepository-Defaults→Repository-Standardlink rot that this fix makes visible is deliberately not absorbed — it is a separate correction with a separate blast radius, tracked as #108.Relevant issues (or links)