Solution Proposal

• Builds on Gardener component model’s dependencies and Gardener CI/CD mechanisms for notification upon dependency release
• Component providers self-register their components in DocHub by creating a docforge manifest.yaml in a .docforge folder in the component repository root. (similar to the role of the Gardener CI/CD .ci folder and pipeline_definition)
• Upon component release, DocHub builds a microsite for the new version of its documentation with Hugo, and publishes it as navigable content on the website along with the rest of the components, and their versions.
• Published component versions are immutable. Changes are made with new releases of the component - major, minor or patch.
• The platform performs scalable delta updates only. It builds only components that released, and publishes only the microsites for them, and not the whole website.
• Microsites can specify additional metadata, e.g. to reference a particular website configuration to use for their build, a human-readable label and description to use when listed.
• Microsites are integrated in a common frame and theme on the website that includes the top-level navigation of the site and presents a coherent UX
• Local previews of microsites can be performed by component owners before pushing changes, using docker containerized build and publish of a stripped down version of the site containing the common frame and their content, but not other components.
• Microsites need to contribute seamlessly to the site SEO and its analytics solution. For example, a component build in DocHub should include auto-generated sitemap.xml for the new component version and the publishing - its integration with the website sitemap.xml.

UI Mockup

Further details

Please, find further sketches of the process flow, including self-registration and build on release in here

from website-generator.

Done

from website-generator.