feat: Read supported versions from the Hub, including nightly - #923
Draft
lfrancke wants to merge 2 commits into
Draft
feat: Read supported versions from the Hub, including nightly#923lfrancke wants to merge 2 commits into
lfrancke wants to merge 2 commits into
Conversation
Regenerates the supported-versions.adoc partials of the product operators from the Stackable Hub API for released docs versions. Nightly keeps the hand-maintained partials since the Hub only knows released data. Responses are cached in the Antora cache dir; the build never fails and never emits warnings when the Hub is unreachable (the production playbook fails builds on warnings). Parked until the Hub exposes the next (unreleased) SDP release: then nightly can be synced from it as well and the operator repos only need to be touched once (delete partials + adopt shared link bar).
Unparks the extension. It previously skipped nightly outright, on the grounds
that the Hub only knew released data, and was held back until a next SDP release
existed so the 16 operator repos would only need visiting once.
The Hub already models this properly, which removes the wait. Both
/api/v1/releases and /api/v1/components/{slug} return a shipped releases array
and a separate upcomingReleases array, and the Hub only exposes an upcoming
release once it is deliberately public -- provisional plans stay private. So
nightly reads upcomingReleases, and the window between a release shipping and the
next one being planned is a normal empty state rather than something to wait out.
It renders as an explicit "not been decided yet" line, and an unreleased list is
labelled provisional so a half-filled one cannot read as a commitment.
Also generates the partial when it is absent instead of only rewriting an
existing one. That is what lets the operator repos delete their copies: two
places include it, an operator's own index.adoc and this repo's platform-wide
operators:supported_versions.adoc, and both have to keep resolving. Since the
extension becomes load-bearing once those copies are gone, a missing partial with
no Hub data now gets a short unavailable note rather than nothing at all, so a
Hub outage still cannot break the build.
Moved from contentAggregated to contentClassified, because adding a file needs
the content catalog and partials are resolved later, when pages are converted.
Verified against a real only-dev build: 13 partials written, the undecided note
renders on both the operator page and the platform overview, addFile round-trips
retrievably in the catalog, and the released path still produces 26.7 as
3.2.2 / 3.1.6 (deprecated) / 3.0.6 (LTS) / 2.9.3 (deprecated), with an unknown
version correctly falling back to the repo copy.
Co-Authored-By: Claude <noreply@anthropic.com>
✅ Deploy Preview for stackable-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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
1 participant
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.
Unparks the Hub supported-versions extension and takes it the rest of the way, so the
supported-versions.adocpartials can be deleted from all 16 operator repos in one visit.Why this was parked, and why it no longer needs to be
The extension previously skipped nightly entirely, on the grounds that the Hub only knew released data. It was held back until a next SDP release existed, so the operator repos would only need touching once rather than twice.
The Hub already models this properly. Both
/api/v1/releasesand/api/v1/components/{slug}return a shippedreleasesarray and a separateupcomingReleasesarray, and the Hub only exposes an upcoming release once it is deliberately public — provisional plans stay private. So there is no heuristic to write and nothing to wait for: nightly readsupcomingReleases, and the window between a release shipping and the next one being planned is a normal empty state.That window renders as an explicit line rather than a blank or a guess:
An unreleased list, once one exists, is labelled provisional, so a half-filled list during the planning weeks cannot read as a commitment.
Creating the partial, not just rewriting it
The bigger change: the extension now creates the partial when it is absent instead of only rewriting an existing one. This is what lets the operator repos delete their copies.
It matters more than it first appears, because two places include that partial:
index.adoc, under its "Supported versions" headingmodules/operators/pages/supported_versions.adoc, which pulls in all 13 product operators via cross-component includesDeleting the repo copies without this would have broken both.
Since the extension becomes load-bearing once those copies are gone, a missing partial with no Hub data now gets a short "unavailable" note rather than nothing at all, so a Hub outage still cannot break a docs build. It continues to cache responses in the Antora cache dir and to log only at info level, because the production playbook fails builds on warnings.
Moved from
contentAggregatedtocontentClassified, since adding a file needs the content catalog and partials are resolved later, when pages are converted.Verification
Against real builds, not reasoning:
make build-only-dev: 13 partials written; the undecided note renders on both the operator page and the platform-wide overview (1 and 13 occurrences respectively).airflow-operator's partial from a local worktree and building withtruly-local-playbook.yml: still 13 written, and zerotarget of include not founderrors. Had it not been created, the include would have failed. The file was restored afterwards.addFileround-trips retrievably viagetByIdunder the samesrckey.Not covered here
upcomingReleasespath is untested, because no public upcoming release exists yet. The empty case is what production renders today, so this is safe to land; the other path wants a look once an upcoming release is published.?release=devalready returns main-branch CRD data, so nightly needs no equivalent handling there.Draft because the sequencing is worth agreeing before it lands, and because publishing an upcoming release in the Portal would let the provisional rendering be seen rather than inferred.