feat: host the provider UI plugin (staff-portal / Workload resource type) - #219
Merged
Conversation
…ype) Mirrors the consumer-ui-plugin work exactly, for the provider side: - ui/provider/workloads/Dockerfile + serve.ts: same bun-build + Bun.serve shape as the consumer plugin (copied verbatim, no cloud-portal-specific references to adapt). Verified locally the same way: docker build/run with a temporary self-signed cert mounted where the CSI volume will be, curl -k the manifest and remoteEntry.js, both 200. - config/components/provider-ui-plugin: Deployment+Service, kind: Component, internal-only (no HTTPRoute), CSI server cert (compute-provider-ui-plugin.compute-system.svc.cluster.local, key-usages: server auth) — folds into compute-manager's own Deployment set via its components: list (companion infra change). - .github/workflows/publish.yaml: new publish-provider-ui-plugin-image job, third images: entry in publish-kustomize-bundles pinning this image's real tag alongside compute's own and the consumer plugin's. - service-configuration.yaml: adds spec.userInterface.provider.assets.baseURL pointing at the new internal Service DNS name. No visibility block (the ProviderPortalPlugin CRD has none) and no caBundle (staff-portal's Deployment already trusts datum-control-plane-ca platform-wide via NODE_EXTRA_CA_CERTS, same as cloud-portal's). Verified: full compute-manager composition (base/manager + every component, including both UI plugins) builds cleanly with all three images present and no cross-contamination.
scotwells
previously approved these changes
Aug 12, 2026
Contributor
There was a problem hiding this comment.
Why have this under a workloads directory?
Contributor
Author
There was a problem hiding this comment.
It made sense to me to leave room in case we wanted to put things related to the compute plugin in here. Like if we did VPC or Storage or "X" as a separate plugin, where it wasn't exposed as part of Workloads but still made sense to live in this repo. Generally speaking if its big enough to have its own service the UI should live in that service, but I wanted it to be purposefully organized from the start.
Contributor
There was a problem hiding this comment.
@kevwilliams VPC / Storage would be in repos focused on those concepts
Contributor
Author
There was a problem hiding this comment.
Ok cool I will remove it, I dont want to spend more time coming up with more examples where it may be useful if we want to be more organized in the future we can add the folders then.
… ui/provider Per review on #219: ui/provider/workloads was the only thing under ui/provider, and future compute-authored plugins for other hosts (e.g. VPC, Storage) would live in their own repos anyway, not nested here — so the extra directory level wasn't buying anything. Flattens both ui/consumer/workloads/* and ui/provider/workloads/* up one level (source files only — dist/ and node_modules/ are gitignored build output, not moved). ui/provider had two READMEs after the move (the old directory-index one, and the plugin's own) — merged into one, since ui/provider/ now *is* the plugin, no further nesting to index. Updated: .github/workflows/publish.yaml's context/dockerfile-path for both image-publish jobs; internal README cross-references between the two plugins' docs. Verified: bun install && bun run build succeeds from the new location for both plugins, docker build/run with a temporary self-signed cert still serves plugin-manifest.json/remoteEntry.js correctly for both, tsc clean, no remaining ui/consumer/workloads or ui/provider/workloads references anywhere in the repo.
scotwells
approved these changes
Aug 12, 2026
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
2 participants
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.
Summary
Mirrors the consumer-ui-plugin work (merged in #215/#217), for the provider side.
ui/provider/workloads/Dockerfile+serve.ts: same bun-build +Bun.serveshape as the consumer plugin. Copied verbatim, no cloud-portal-specific references to adapt. Verified locally:docker build/runwith a temporary self-signed cert mounted where the CSI volume will be,curl -kthe manifest andremoteEntry.js, both200.config/components/provider-ui-plugin: Deployment+Service,kind: Component, internal-only, no HTTPRoute. CSI server cert (compute-provider-ui-plugin.compute-system.svc.cluster.local,key-usages: server auth). Folds intocompute-manager's own Deployment set via itscomponents:list (companion infra PR)..github/workflows/publish.yaml: newpublish-provider-ui-plugin-imagejob. Thirdimages:entry inpublish-kustomize-bundles, pinning this image's real tag alongsidecompute's own and the consumer plugin's.service-configuration.yaml: addsspec.userInterface.provider.assets.baseURL, pointing at the new internal Service DNS name. Novisibilityblock. TheProviderPortalPluginCRD has none. NocaBundle. staff-portal's Deployment already trustsdatum-control-plane-caplatform-wide viaNODE_EXTRA_CA_CERTS, same reasoning as the consumer plugin.Test plan
docker build/runlocally, TLS server block and manifest/remoteEntry serve200kustomize build config/components/provider-ui-pluginrenders cleanly standalonecompute-managercomposition (all components, including both UI plugins) builds cleanly, three images present, no cross-contaminationkubectl get providerportalpluginsshows acomputeentry, staff-portal logs showlisted 1 ProviderPortalPlugin(s), "Workload" appears as a Type filter on/customers/resources