Red Hat shows how Developer Hub can make the CI/CD stack one golden path

Red Hat has published a worked example of the platform-engineering promise behind Developer Hub: one self-service template that creates an application repository, wires in CI and GitOps, registers the component and exposes operational status without asking the developer to assemble the toolchain manually.

The value is less the individual tools than the connective tissue between them.

One template, several control planes

The Red Hat Developer guide extends an earlier setup that enabled Developer Hub plug-ins for Tekton, Argo CD, Quay and Kubernetes. Its sample software template collects the project name, owner, system, registry, namespace and target cluster before generating a Go application skeleton.

The generated repository includes a Tekton pipeline, Argo CD manifests, a devfile and the catalog-info.yaml metadata that Developer Hub uses to register the component. The template then publishes the repository to GitHub, creates an Argo CD application against the manifests directory and adds the new component to the software catalog.

That sequence is a concrete definition of a golden path: the platform team owns the integration decisions, while the developer supplies only the application-specific inputs.

Metadata is the integration layer

The guide’s most useful detail is its treatment of catalog annotations. Developer Hub does not infer the entire delivery topology from a repository. The catalog entity must identify the Kubernetes workload and namespace, connect the Tekton resources, point to the Argo CD application and name the Quay repository.

Those annotations determine whether the component page can show pods and deployments, PipelineRuns and logs, GitOps synchronization and health, and container image metadata. Red Hat notes that missing or incorrect annotations are the main reason plug-in tabs appear empty.

For platform teams, that makes catalog-info.yaml part of the product contract rather than incidental documentation. Template changes need the same review and testing discipline as pipeline or deployment changes because a stale label selector or repository slug can break the developer portal’s view even when the workload itself still runs.

Where to apply caution

The sample is deliberately specific. It contains example GitHub ownership and Quay repository values that adopters must replace. It also assumes the earlier work of configuring secrets, plug-ins, role-based access controls and service-account permissions has already been completed.

Teams adopting the pattern should therefore split validation into two paths: test whether the template provisions the delivery assets correctly, then test whether every catalog annotation surfaces the intended data to the right users. A successful scaffold with an empty operations view is only half a golden path.

The broader lesson is clear: Developer Hub can provide a unified experience without replacing Tekton, Argo CD, Quay or OpenShift. Its role is to package their interfaces into a paved workflow and keep the links between them legible.