The BUNDLES catalog was a hardcoded list of 8.1.x docIds with no
version discovery, so the weekly refresh never picked up Morpheus
Enterprise 9.0.0 (published May 2026 under new HPE docIds). --force
only re-fetches known pages; it never finds new bundles.
- Pin 9.0.0 explicitly: User Manual sd00008014en_us (toc, 623 pages)
and Release Notes sd00008017en_us (single). docIds confirmed by
probing the HPE DocPortal on 2026-07-15.
- Add _discover_enterprise(): each run sweeps the docId range forward
from the pinned floor and appends any newer Enterprise User Manuals
/ Release Notes, so future versions (9.0.1, ...) land without a code
edit. Filters sibling products (VM Essentials, Morpheus Central),
matches title+abstract (the RN <h1> is only "vX.Y.Z Release Notes"),
and deterministically prefers the lowest docId on HPE's mirror dupes.
- Best-effort: per-id errors are swallowed and any top-level failure
falls back to the pinned list. Gate off with DISCOVER_VERSIONS=0 or
--no-discover.
Verified live: against only the 8.1.x pins, discovery surfaces 9.0.0
on its own; full run yields 9 bundles / 2334 pages in ~18s.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01LFowQzJu7k97QLCRDSAeh1
First dispatch on the empty template failed at Chroma collection
creation because PRODUCT_NAME was the literal string "<product>"
(YAML doesn't expand placeholders), and Chroma rejects collection
names containing characters outside [a-zA-Z0-9._-]:
chromadb.errors.InvalidArgumentError: Validation error: name:
Expected a name containing 3-512 characters from [a-zA-Z0-9._-],
starting and ending with a character in [a-zA-Z0-9]. Got:
<product>_docs
Same fix as the IMAGE env: derive from the repo name dynamically
via ${{ github.event.repository.name }}. Cloners can still override
explicitly, but a fresh clone now runs the index-rebuild step
cleanly out of the box.
Verified by re-dispatch — should fail next at docker login (placeholder
REGISTRY_PUSH hostname), which is the next-expected fail point and a
real per-deployment config the cloner has to fill in.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Both workflows had a static IMAGE env (<owner>/<product>-docs-mcp)
and a static --package arg in the GC step. Switch both to Gitea
Actions context variables so a clone of the template into any repo
name works on the first CI run without find/replace:
IMAGE: ${{ github.repository_owner }}/${{ github.event.repository.name }}
--owner ${{ github.repository_owner }}
--package ${{ github.event.repository.name }}
Also add the "Link container package to this repo" step that was
missing from the template (and which, naively copy-pasted from the
reference build, would have linked everything back to docs-mcp-
template). The new step derives owner + package + link-target all
from the running repo's context.
The github.* namespace is Gitea Actions' inherited GitHub-Actions
context — values come from the Gitea server, not github.com. Same
mechanism the reference build's $GITHUB_SHA tag-builder uses.
CLAUDE.md updated to note that image and package naming are
repo-derived; only registry endpoints and the Ollama URL need
per-clone editing.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
claudeandClaude Opus 4.8
justin
hvm-docs-refresh