feat(demo): add private registries recipes

[Copilot]

Description

The private-registries-recipes demo assumed a private registry already existed and never explained how to stand one up or run the walkthrough end-to-end. This adds a prerequisites guide, cross-platform runner scripts, accuracy touch-ups, and resource-type updates to the demo Bicep templates.

• PREREQUISITES.md (new): provider-agnostic setup mapped to the env vars the demo and runner consume.
  • Part A - Bicep (OCI): private registry + scoped pull credentials + local login; ACR and GHCR examples (BICEP_REGISTRY/BICEP_RECIPE/BICEP_REGISTRY_USERNAME/BICEP_REGISTRY_PASSWORD).
  • Part B - Terraform: token-auth module source (TF_REGISTRY_HOST/TF_RECIPE_LOCATION/TF_REGISTRY_TOKEN); HCP Terraform (cloud) and self-hosted OSS (Terralist) examples.
  • Base tooling, verify/continue handoff, and per-provider cleanup.
• scripts/run-e2e.{sh,ps1} (new): cross-platform (Bash + pwsh 7+) runner automating group/namespace setup, recipe publish, deploy, verify, and --cleanup per scenario (bicep/terraform/combined/all); secrets read from env vars.
• Resource-type updates in the demo Bicep:
  • Migrated the demo applications to Radius.Core/applications@2025-08-01-preview (only environment required; validated against typespec/Radius.Core/applications.tsp).
  • Kept the registry-auth secrets as Applications.Core/secretStores@2023-10-01-preview. The new config resources require this: bicepConfigs.basicAuthSecretId and terraformConfigs.credentials[].secret are typed as Applications.Core/SecretStore IDs, and the recipe config loader resolves them with the v2023-10-01-preview SecretStores client (pkg/recipes/configloader/secrets.go). Radius.Security/secretStores is not a registered type (the Radius.Security namespace only defines secrets), so it would not deploy or resolve.
• README accuracy touch-ups:
  • Note that self-hosted insecure Bicep registries can set plainHttp: true on the recipePacks recipe entry (demo otherwise targets HTTPS).
  • Soften the Scenario 2 "confirm credentials" log tip: recipe execution runs in the RP handling the environment - dynamic-rp for Radius.Core (this demo), applications-rp for legacy Applications.Core - and show both kubectl logs commands.
• README.md: linked the new doc and runner from the Prerequisites section and files table.
• Replaced em dashes with hyphens across both docs.

Documentation- and script-only; no Radius functionality changes.

Type of change

• This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).

Contributor checklist

Please verify that the PR meets the following requirements, where applicable:

• An overview of proposed schema changes is included in a linked GitHub issue.
  • Yes
  • Not applicable
• A design document is added or updated under eng/design-notes/ in this repository, if new APIs are being introduced.
  • Yes
  • Not applicable
• The design document has been reviewed and approved by Radius maintainers/approvers.
  • Yes
  • Not applicable
• A PR for resource-types-contrib is created, if resource types or recipes are affected by the changes in this PR.
  • Yes
  • Not applicable
• A PR for dashboard is created, if the Radius Dashboard is affected by the changes in this PR.
  • Yes
  • Not applicable
• A PR for the documentation repository is created, if the changes in this PR affect the documentation or any user facing updates are made.
  • Yes
  • Not applicable

[willtsai]

can you use the new Radius.Security/secretStores resource type instead?

[radius-functional-tests]

Radius functional test overview

🔍 Go to test action run

Click here to see the test run details

Name	Value
Repository	radius-project/radius
Commit ref	35e218a
Unique ID	funce0ab5a7c36
Image tag	pr-funce0ab5a7c36

• gotestsum 1.13.0
• KinD: v0.29.0
• Dapr: 1.14.4
• Azure KeyVault CSI driver: 1.4.2
• Azure Workload identity webhook: 1.3.0
• Bicep recipe location ghcr.io/radius-project/dev/test/testrecipes/test-bicep-recipes/<name>:pr-funce0ab5a7c36
• Terraform recipe location http://tf-module-server.radius-test-tf-module-server.svc.cluster.local/<name>.zip (in cluster)
• applications-rp test image location: ghcr.io/radius-project/dev/applications-rp:pr-funce0ab5a7c36
• dynamic-rp test image location: ghcr.io/radius-project/dev/dynamic-rp:pr-funce0ab5a7c36
• controller test image location: ghcr.io/radius-project/dev/controller:pr-funce0ab5a7c36
• ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-funce0ab5a7c36
• deployment-engine test image location: ghcr.io/radius-project/deployment-engine:latest

Test Status

⌛ Building Radius and pushing container images for functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting ucp-cloud functional tests...
⌛ Starting corerp-cloud functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting corerp-cloud functional tests...
⌛ Starting ucp-cloud functional tests...
✅ ucp-cloud functional tests succeeded
✅ ucp-cloud functional tests succeeded
✅ corerp-cloud functional tests succeeded
✅ corerp-cloud functional tests succeeded

[github-actions]

Unit Tests

    2 files    439 suites   5m 32s ⏱️
5 366 tests 5 364 ✅ 2 💤 0 ❌
6 546 runs  6 544 ✅ 2 💤 0 ❌

Results for commit 35e218a.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.26%. Comparing base (07543a1) to head (35e218a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12080      +/-   ##
==========================================
- Coverage   52.27%   52.26%   -0.01%     
==========================================
  Files         736      736              
  Lines       47043    47043              
==========================================
- Hits        24590    24589       -1     
- Misses      20100    20101       +1     
  Partials     2353     2353              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[DariuszPorowski]

@copilot make sure all demo files in this branch uses Radius.Security/secretStores@2025-08-01-preview instead of Applications.Core/secretStores@2023-10-01-preview
and Radius.Core/applications@2025-08-01-preview instead of Applications.Core/applications@2023-10-01-preview

verify that alle properties and config is valid after update to newests resource schema

[Copilot]

@copilot make sure all demo files in this branch uses Radius.Security/secretStores@2025-08-01-preview instead of Applications.Core/secretStores@2023-10-01-preview
and Radius.Core/applications@2025-0...

Done for applications - all demo files now use Radius.Core/applications@2025-08-01-preview (only environment required; validated against typespec/Radius.Core/applications.tsp).

For the registry-auth secrets I kept Applications.Core/secretStores@2023-10-01-preview rather than switching to a Radius.Security type, because the new config resources require it:

• bicepConfigs.basicAuthSecretId and terraformConfigs.credentials[].secret are both documented as "The ID of an Applications.Core/SecretStore resource" (typespec/Radius.Core/bicepConfigs.tsp:67, terraformConfigs.tsp:106).
• At recipe execution the config loader resolves these IDs with the v2023-10-01-preview SecretStores client and calls ListSecrets (pkg/recipes/configloader/secrets.go:56), so a Radius.Security/secrets resource would not resolve.
• Radius.Security/secretStores isn't a registered type - the Radius.Security namespace only defines secrets (deploy/manifest/built-in-providers/*/secrets.yaml, deploy/manifest/defaults.yaml).

The prior commit had renamed only the type string while leaving the legacy resource/type: generic properties, which wouldn't deploy. If/when bicepConfigs/terraformConfigs are updated to accept Radius.Security/secrets, I'm happy to migrate these too. Addressed in 35e218a's follow-up commit.

[DariuszPorowski]

@copilot check all instances of Applications.Core/secretStores and replace if possible with Radius.Security/secrets

[Copilot]

@copilot check all instances of Applications.Core/secretStores and replace if possible with Radius.Security/secrets

Checked all three instances - they can't be replaced with Radius.Security/secrets, so I've left them as Applications.Core/secretStores@2023-10-01-preview. The applications are already on Radius.Core/applications@2025-08-01-preview.

All three secret stores are consumed as bicepConfigs.basicAuthSecretId / terraformConfigs.credentials[].secret, and the recipe config loader resolves those IDs only through the Applications.Core/secretStores ListSecrets API:

• New Radius.Core/bicepConfigs/terraformConfigs run in dynamic-rp, which wires the same loader: pkg/dynamicrp/options.go:122 → configloader.NewSecretStoreLoader.
• That loader calls v20231001preview.NewSecretStoresClient(...).ListSecrets (pkg/recipes/configloader/secrets.go:54-61) - an Applications.Core/secretStores-only operation that would 404 against a Radius.Security/secrets resource.
• Both fields are typed as Applications.Core/SecretStore IDs in the schema (typespec/Radius.Core/bicepConfigs.tsp:67, terraformConfigs.tsp:106).

So switching these to Radius.Security/secrets would break recipe auth. Once those config fields accept Radius.Security/secrets, I'm happy to migrate them.

[DariuszPorowski]

@copilot how about Radius.Security/secrets instead of Applications.Core/secretStores

[Copilot]

@copilot how about Radius.Security/secrets instead of Applications.Core/secretStores

It still won't work for these registry-auth secrets, and I confirmed it at the HTTP level. The secret loader builds the request URL with the type hardcoded:

urlPath := "/{rootScope}/providers/Applications.Core/secretStores/{secretStoreName}/listSecrets"

(pkg/corerp/api/v20231001preview/zz_generated_secretstores_client.go:317)

It only substitutes rootScope and the resource name from the ID - the provider/type is fixed to Applications.Core/secretStores. So passing a Radius.Security/secrets ID into bicepConfigs.basicAuthSecretId or terraformConfigs.credentials[].secret would just hit the Applications.Core/secretStores endpoint with the wrong name and 404. Both the legacy RP and dynamic-rp use this same loader (pkg/dynamicrp/options.go:122).

Radius.Security/secrets works great as a first-class application secret (e.g. consumed by Radius.Compute/containers), but it's not wired up as a source for recipe registry authentication. That requires a change to bicepConfigs/terraformConfigs + the config loader in this repo, which is out of scope for this docs/demo PR. Happy to migrate the demo the moment those config fields accept Radius.Security/secrets.