Summary
The live Antora docs site (https://skainet-developers.github.io/SKaiNET/skainet/) is
stale — it's missing content that's been in develop for a while (e.g. SKEEP-002 and
SKEEP-003 are in docs/modules/skeep/nav.adoc and index.adoc today, reachable from
tag 0.40.1, but don't appear on the live site).
Root cause: .github/workflows/docs.yml's deploy-docs job is gated on
if: github.event_name == 'release' (a GitHub Release object being published), with
the comment "Canonical site = latest release. Deploy only on a published release."
But this repo's actual release process only ever pushes a git tag (0.40.1,
0.39.1, etc.) — no GitHub Release object is ever created (gh release list returns
empty; zero releases, ever). Confirmed via Actions history: every historical run of
docs.yml has event: push or event: pull_request; event: release has never
fired. So deploy-docs has never run, and the live site reflects whatever was
deployed by some earlier/manual mechanism, frozen since.
Fix options
Pick one (not proposing a specific choice, this is a process decision):
- Deploy on tag push — add
push: tags: '**' (or filtered to release-version tag
patterns) as a trigger, matching how the actual release workflow (publish.yml,
SKaiNET-transformers side) already triggers off tags rather than Releases.
- Create real GitHub Releases as part of the release process (
gh release create
after tagging) — makes the existing release: published trigger actually fire, and
gets the repo real Release notes pages as a side benefit.
- Deploy on every push to
develop — simplest, matches build-docs's existing
trigger; loses the "canonical site = latest release" framing but guarantees the
site is never more than one merge behind.
Related
Related to (but distinct from) versioning the docs site — see the separate issue for
that. This issue is about the current single version not being deployed at all,
independent of whether the site ever supports multiple versions.
Summary
The live Antora docs site (https://skainet-developers.github.io/SKaiNET/skainet/) is
stale — it's missing content that's been in
developfor a while (e.g. SKEEP-002 andSKEEP-003 are in
docs/modules/skeep/nav.adocandindex.adoctoday, reachable fromtag
0.40.1, but don't appear on the live site).Root cause:
.github/workflows/docs.yml'sdeploy-docsjob is gated onif: github.event_name == 'release'(a GitHub Release object being published), withthe comment "Canonical site = latest release. Deploy only on a published release."
But this repo's actual release process only ever pushes a git tag (
0.40.1,0.39.1, etc.) — no GitHub Release object is ever created (gh release listreturnsempty; zero releases, ever). Confirmed via Actions history: every historical run of
docs.ymlhasevent: pushorevent: pull_request;event: releasehas neverfired. So
deploy-docshas never run, and the live site reflects whatever wasdeployed by some earlier/manual mechanism, frozen since.
Fix options
Pick one (not proposing a specific choice, this is a process decision):
push: tags: '**'(or filtered to release-version tagpatterns) as a trigger, matching how the actual release workflow (
publish.yml,SKaiNET-transformers side) already triggers off tags rather than Releases.
gh release createafter tagging) — makes the existing
release: publishedtrigger actually fire, andgets the repo real Release notes pages as a side benefit.
develop— simplest, matchesbuild-docs's existingtrigger; loses the "canonical site = latest release" framing but guarantees the
site is never more than one merge behind.
Related
Related to (but distinct from) versioning the docs site — see the separate issue for
that. This issue is about the current single version not being deployed at all,
independent of whether the site ever supports multiple versions.