Hydrate Radius.Core schemas from OpenAPI#11881
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #11881 +/- ##
==========================================
- Coverage 51.74% 51.71% -0.03%
==========================================
Files 726 727 +1
Lines 45605 45712 +107
==========================================
+ Hits 23597 23642 +45
- Misses 19788 19822 +34
- Partials 2220 2248 +28 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR fixes missing schema/description metadata for built-in Radius.Core resource types by hydrating the manifest metadata from the embedded TypeSpec-generated OpenAPI document during UCP startup, improving rad resource-type show and Dashboard schema rendering for applications, environments, and recipePacks.
Changes:
- Hydrates
Radius.Coreresource type descriptions and per-API-version schemas from the embedded OpenAPI spec during initializer registration. - Expands local OpenAPI
#/definitions/*refs into concrete schemas before persisting intoAPIVersionandResourceProviderSummary. - Adds a regression test that registers the real built-in
radius_core.yamlmanifest and asserts schemas are populated and$ref-free for renderability.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| pkg/ucp/initializer/service.go | Invokes built-in metadata hydration before persisting provider/type/version resources. |
| pkg/ucp/initializer/radius_core_openapi.go | Loads embedded Radius.Core OpenAPI and resolves #/definitions/* refs to hydrate descriptions and schemas. |
| pkg/ucp/initializer/service_test.go | Adds regression coverage validating hydrated schemas/descriptions are persisted and renderable. |
| // bypassing the HTTP API and async operation queue. This is used during server initialization | ||
| // where the resources are known to not exist yet. | ||
| func registerResourceProviderDirect(ctx context.Context, dbClient database.Client, planeName string, rp manifest.ResourceProvider) error { | ||
| if err := hydrateBuiltInResourceProviderMetadata(&rp); err != nil { |
There was a problem hiding this comment.
suggestion: this call is independant and should be at ln90, not within registerResourceProviderDirect (SRP)
There was a problem hiding this comment.
Addressed in f9bfc3884. The hydration call now happens in Service.Run immediately after manifest validation and before direct registration, so registerResourceProviderDirect is back to only persisting the already-prepared resource provider metadata.
Validation run:
go test ./pkg/ucp/initializer ./pkg/cli/cmd/resourcetype/show ./pkg/cli/cmd/resourcetype/common ./pkg/cli/manifest ./pkg/schema
willdavsmith
force-pushed
the
willdavsmith/10894
branch
from
2897bc3 to
f9bfc38
Compare
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
|
nit: The functions e.g. |
| openAPIDefinitionRefRoot = "#/definitions/" | ||
| ) | ||
|
|
||
| var radiusCoreTypeOpenAPIDefinitions = map[string]struct { |
There was a problem hiding this comment.
the PR does not include new types added in main: terraformConfigs, bicepConfigs
This is a gap. should we raise an error if the openapi file has a type with no matching entry ?
Summary
Fixes #10894 by hydrating Radius.Core resource type metadata from the generated OpenAPI spec during UCP startup.
The built-in manifests can stay minimal, while UCP registration fills descriptions and schemas for Radius.Core/applications, Radius.Core/environments, and Radius.Core/recipePacks.
Root Cause
The Radius.Core built-in manifests register these resource types with empty schemas. rad resource-type show reads ResourceProviderSummary, so the CLI and dashboard only saw empty descriptions and null schemas for these built-in types.
What Changed
User Experience
Before
Users could discover that Radius.Core/applications, Radius.Core/environments, and Radius.Core/recipePacks existed, but the type details were effectively empty.
For example:
returned only the type name and API version:
JSON output also showed the missing metadata:
In the Dashboard, these built-in Radius.Core types appeared without useful schema/property information, so users could not inspect required fields, read-only fields, nested properties, or property descriptions.
After
Users can inspect the built-in Radius.Core types the same way they inspect other registered resource types.
For example:
now shows the generated TypeSpec/OpenAPI metadata:
The same improvement applies to:
Dashboard and CLI users now get meaningful descriptions and schema details for these built-in types without duplicating schemas in the manifest YAML.
Validation