feat(demo): add private registries recipes#12080
Conversation
|
|
||
| // SecretStore holding the username/password used to authenticate to the private | ||
| // OCI registry. For BasicAuth the secret store must expose 'username' and 'password'. | ||
| resource registrySecret 'Applications.Core/secretStores@2023-10-01-preview' = { |
There was a problem hiding this comment.
can you use the new Radius.Security/secretStores resource type instead?
Done for For the registry-auth secrets I kept
The prior commit had renamed only the type string while leaving the legacy |
|
@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 All three secret stores are consumed as
So switching these to |
|
@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: ( It only substitutes
|
…ig resource types
Signed-off-by: Dariusz Porowski <[email protected]>
…equired by recipe config loader)
14e8cdb to
891c958
Compare
Yes - PR #12181 ("Refactor recipe settings resources to match the feature spec and support Radius.Security/secrets", fixes #12122) directly removes the blocker I described. It makes the recipe secret loader parse the referenced secret ID and dispatch on type instead of hardcoding the Two things to note so the migration is done correctly when it lands - it's more than a type-string swap:
The migrated shape (from that PR's resource registryToken 'Radius.Security/secrets@2025-08-01-preview' = {
name: 'tfsec-registry-token'
properties: {
environment: secretsEnvironment
data: { token: { value: '...' } }
}
}
resource tfConfig 'Radius.Core/terraformSettings@2025-08-01-preview' = {
name: 'tfsec-terraform-config'
properties: {
terraformrc: { credentials: { 'app.terraform.io': { secret: registryToken.id } } }
}
}Status: #12181 is still open and not merged (currently shows merge conflicts with |
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
Description
The
private-registries-recipesdemo 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.BICEP_REGISTRY/BICEP_RECIPE/BICEP_REGISTRY_USERNAME/BICEP_REGISTRY_PASSWORD).TF_REGISTRY_HOST/TF_RECIPE_LOCATION/TF_REGISTRY_TOKEN); HCP Terraform (cloud) and self-hosted OSS (Terralist) examples.scripts/run-e2e.{sh,ps1}(new): cross-platform (Bash +pwsh7+) runner automating group/namespace setup, recipe publish, deploy, verify, and--cleanupper scenario (bicep/terraform/combined/all); secrets read from env vars.Radius.Core/applications@2025-08-01-preview(onlyenvironmentrequired; validated againsttypespec/Radius.Core/applications.tsp).Applications.Core/secretStores@2023-10-01-preview. The new config resources require this:bicepConfigs.basicAuthSecretIdandterraformConfigs.credentials[].secretare typed asApplications.Core/SecretStoreIDs, and the recipe config loader resolves them with the v2023-10-01-preview SecretStores client (pkg/recipes/configloader/secrets.go).Radius.Security/secretStoresis not a registered type (theRadius.Securitynamespace only definessecrets), so it would not deploy or resolve.plainHttp: trueon therecipePacksrecipe entry (demo otherwise targets HTTPS).dynamic-rpforRadius.Core(this demo),applications-rpfor legacyApplications.Core- and show bothkubectl logscommands.README.md: linked the new doc and runner from the Prerequisites section and files table.Documentation- and script-only; no Radius functionality changes.
Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:
eng/design-notes/in this repository, if new APIs are being introduced.