Skip to content

Fix rad deploy resolving Radius.Core environment ID in the wrong group - #12599

Merged
brooke-hamilton merged 4 commits into
radius-project:mainfrom
pujitha24:auto/issue-12573
Aug 20, 2026
Merged

brooke-hamilton merged 4 commits into
radius-project:mainfrom
pujitha24:auto/issue-12573

Conversation

@pujitha24

Copy link
Copy Markdown
Contributor

Motivation:
When a workspace's default environment is stored as a full Radius.Core
resource ID (e.g. created via rad init in preview mode), running
rad deploy <template> -g <group> against a resource group other than
the environment's own group failed with "The environment ... does not
exist in scope ...", even though rad deploy --help and the rad group
command's own documentation state that an application's resources do
not have to live in the same resource group as the environment they
reference, and that passing a full environment ID is the documented way
to use an environment from a different group.

Approach:
FetchEnvironment in pkg/cli/cmd/deploy/deploy.go already handled this
correctly for Applications.Core environments (it passes the full ID
through to GetEnvironment, which extracts scope from the ID). The
Radius.Core branch instead discarded the full ID's own resource group
and re-queried using only the environment name against
r.Workspace.Scope (the --group-overridden scope), so a Radius.Core
environment could never be reused across resource groups. This change
brings the Radius.Core branch in line with the Applications.Core branch:
when the environment reference is a full resource ID, the lookup now
uses the scope encoded in that ID (envID.RootScope()) instead of the
deploy-time --group scope. The "environment does not exist" error
message in Validate() is also updated to report the scope that was
actually checked, instead of always reporting the --group scope,
which was misleading in this case.

Note: user-visible behavior for the common case (deploying into the
same group as the environment) is unchanged; this only affects
deployments that use -g/--group with an environment stored/passed
as a full Radius.Core resource ID belonging to a different group.

Validation:

  • go build ./...
  • go test ./pkg/cli/cmd/deploy/... ./pkg/cli/cmd/run/... -count=1 (both ok)
  • CGO_ENABLED=1 go test ./pkg/cli/cmd/... ./cmd/rad/... -timeout 600s
    (the command run by the documented make test-validate-cli target
    per docs/contributing/contributing-code/contributing-code-tests/README.md)
    — all packages pass
  • Added Test_FetchEnvironment_RadiusCoreEnvironmentUsesOwnGroup, which
    reproduces the reported failure with a fake Radius.Core environment
    server that 404s unless queried with the environment ID's own scope;
    confirmed this test fails against the pre-fix code and passes with
    the fix by temporarily reverting the scope-selection change and
    rerunning it.

Report: #12573
Signed-off-by: Pujitha Paladugu 10557236+pujitha24@users.noreply.github.com

Fixes #12573

@pujitha24
pujitha24 requested review from a team as code owners August 2, 2026 00:27
Copilot AI review requested due to automatic review settings August 2, 2026 00:27
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 2, 2026 00:27 — with GitHub Actions Failure

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes rad deploy -g <group> incorrectly resolving a workspace default Radius.Core environment ID against the deploy-time --group scope instead of the scope encoded in the full environment resource ID, preventing reuse of environments across resource groups.

Changes:

  • Use envID.RootScope() when fetching Radius.Core environments referenced by full resource ID, aligning behavior with the existing Applications.Core lookup path.
  • Improve the “environment does not exist” validation error to report the scope that was actually checked (ID-encoded scope when a full ID is provided).
  • Add a regression test covering Radius.Core environment resolution across differing environment/deploy scopes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
pkg/cli/cmd/deploy/deploy.go Fixes Radius.Core environment lookup to use ID-encoded scope and improves the related validation error message.
pkg/cli/cmd/deploy/deploy_test.go Updates existing Radius.Core env tests for the new signature and adds a regression test for cross-group environment resolution.

Comment thread pkg/cli/cmd/deploy/deploy_test.go Outdated
@codecov

codecov Bot commented Aug 3, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.37%. Comparing base (ab0a17a) to head (6d11be4).

Files with missing lines Patch % Lines
pkg/cli/cmd/deploy/deploy.go 77.77% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #12599      +/-   ##
==========================================
+ Coverage   54.36%   54.37%   +0.01%     
==========================================
  Files         770      770              
  Lines       51299    51304       +5     
==========================================
+ Hits        27890    27899       +9     
+ Misses      20795    20792       -3     
+ Partials     2614     2613       -1     

☔ 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.

@lakshmimsft

Copy link
Copy Markdown
Contributor

Thank you for the submission. This issue is pending a discussion with the PMs. @willtsai , @zachcasper

@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 8, 2026 02:32 — with GitHub Actions Failure
@pujitha24

Copy link
Copy Markdown
Contributor Author

Thanks for the update, @lakshmimsft — understood that this is pending discussion with the PMs, so I'll hold off on further changes here until that's resolved. In the meantime I addressed Copilot's review comment on Test_getRadiusCoreEnvironment (it was passing a full resource ID directly as the environmentName argument, which doesn't match how the real API or FetchEnvironment use it); the test now extracts scope/name from the ID first, matching production behavior. Happy to make further changes once there's guidance from the PM discussion.

@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 9, 2026 20:54 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 10, 2026 23:26 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 12, 2026 00:39 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 12, 2026 13:45 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 13, 2026 00:27 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 13, 2026 17:32 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 14, 2026 01:31 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 14, 2026 21:27 — with GitHub Actions Failure
@brooke-hamilton
brooke-hamilton self-requested a review August 17, 2026 18:14
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 17, 2026 19:09 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 17, 2026 20:46 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 18, 2026 09:36 — with GitHub Actions Failure
@zachcasper

Copy link
Copy Markdown
Contributor

Working as promised.

Before:

❯ rad deploy default-recipes.bicep -g test
Building default-recipes.bicep...
The environment "/planes/radius/local/resourceGroups/default/providers/Radius.Core/environments/default" does not exist in scope "/planes/radius/local/resourceGroups/test". Run `rad env create` first. You could also provide the environment ID if the environment exists in a different group.

After:

❯ ~/radius/dev/radius-project/radius/dist/darwin_arm64/release/rad deploy default-recipes.bicep -g test
Building default-recipes.bicep...
Deploying template 'default-recipes.bicep' into environment '/planes/radius/local/resourcegroups/default/providers/Radius.Core/environments/default' from workspace 'default'...

Deployment In Progress...


Deployment Complete

Resources:
    test            Radius.Core/recipePacks

zachcasper
zachcasper previously approved these changes Aug 18, 2026
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 18, 2026 17:04 — with GitHub Actions Failure
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 19, 2026 08:29 — with GitHub Actions Failure
@brooke-hamilton

Copy link
Copy Markdown
Member

Hi @pujitha24, thank you for contributing to Radius.

The following commits do not currently show a GitHub Verified signature:

Please follow our commit-signing guide to configure GPG, SSH, or S/MIME signing. Then re-sign the affected commits and force-push the rewritten branch with --force-with-lease.

Cryptographic commit signing is separate from the DCO Signed-off-by line; both are required.

@pujitha24

Copy link
Copy Markdown
Contributor Author

@brooke-hamilton good catch — d1a8154, 6733235, cbd79fe, and 318d590 went in unsigned. Commit signing is configured on my side now (ssh format), but it wasn't in effect when these landed, so there's nothing to verify on them as-is. Fixing that means rebasing to re-sign each commit and force-pushing the branch, which isn't something I can do in this pass — I'll follow up on that separately rather than leave it broken.

@zachcasper thanks for confirming it works as expected — good to have that verified end-to-end.

Motivation:
When a workspace's default environment is stored as a full Radius.Core
resource ID (e.g. created via `rad init` in preview mode), running
`rad deploy <template> -g <group>` against a resource group other than
the environment's own group failed with "The environment ... does not
exist in scope ...", even though `rad deploy --help` and the `rad group`
command's own documentation state that an application's resources do
not have to live in the same resource group as the environment they
reference, and that passing a full environment ID is the documented way
to use an environment from a different group.

Approach:
`FetchEnvironment` in pkg/cli/cmd/deploy/deploy.go already handled this
correctly for Applications.Core environments (it passes the full ID
through to GetEnvironment, which extracts scope from the ID). The
Radius.Core branch instead discarded the full ID's own resource group
and re-queried using only the environment name against
`r.Workspace.Scope` (the `--group`-overridden scope), so a Radius.Core
environment could never be reused across resource groups. This change
brings the Radius.Core branch in line with the Applications.Core branch:
when the environment reference is a full resource ID, the lookup now
uses the scope encoded in that ID (`envID.RootScope()`) instead of the
deploy-time `--group` scope. The "environment does not exist" error
message in Validate() is also updated to report the scope that was
actually checked, instead of always reporting the `--group` scope,
which was misleading in this case.

Note: user-visible behavior for the common case (deploying into the
same group as the environment) is unchanged; this only affects
deployments that use `-g`/`--group` with an environment stored/passed
as a full Radius.Core resource ID belonging to a different group.

Validation:
- go build ./...
- go test ./pkg/cli/cmd/deploy/... ./pkg/cli/cmd/run/... -count=1 (both ok)
- CGO_ENABLED=1 go test ./pkg/cli/cmd/... ./cmd/rad/... -timeout 600s
  (the command run by the documented `make test-validate-cli` target
  per docs/contributing/contributing-code/contributing-code-tests/README.md)
  — all packages pass
- Added Test_FetchEnvironment_RadiusCoreEnvironmentUsesOwnGroup, which
  reproduces the reported failure with a fake Radius.Core environment
  server that 404s unless queried with the environment ID's own scope;
  confirmed this test fails against the pre-fix code and passes with
  the fix by temporarily reverting the scope-selection change and
  rerunning it.

Report: radius-project#12573
Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
…etRadiusCoreEnvironment

Test_getRadiusCoreEnvironment was passing a full Radius.Core resource ID
directly as the environmentName argument to getRadiusCoreEnvironment,
which doesn't reflect how the real EnvironmentsClient.Get API or the
production caller (FetchEnvironment) use it. Extract scope/name from the
ID before calling, matching FetchEnvironment's own envID.RootScope() /
envID.Name() usage, and update the expected environment name to the bare
name.

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
…t_RadiusCoreEnvironmentUsesOwnGroup

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
@pujitha24
pujitha24 had a problem deploying to external-contributor-approval August 19, 2026 17:45 — with GitHub Actions Failure
@pujitha24
pujitha24 deployed to external-contributor-approval August 20, 2026 08:35 — with GitHub Actions Active
@brooke-hamilton brooke-hamilton added the pr:standard Ongoing maintenance, minor improvements, documentation updates, and routine development work label Aug 20, 2026
@radius-functional-tests

radius-functional-tests Bot commented Aug 20, 2026 •

Copy link
Copy Markdown

Radius functional test overview

🔍 Go to test action run

Click here to see the test run details
Name Value
Repository pujitha24/radius
Commit ref 6d11be4
Unique ID func12934a4d73
Image tag pr-func12934a4d73
  • 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-func12934a4d73
  • 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-func12934a4d73
  • dynamic-rp test image location: ghcr.io/radius-project/dev/dynamic-rp:pr-func12934a4d73
  • controller test image location: ghcr.io/radius-project/dev/controller:pr-func12934a4d73
  • ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-func12934a4d73
  • 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 corerp-cloud functional tests...
⌛ Starting ucp-cloud functional tests...
✅ ucp-cloud functional tests succeeded
❌ corerp-cloud functional test failed. Please check the logs for more details
⌛ Starting corerp-cloud functional tests...
❌ corerp-cloud functional test failed. Please check the logs for more details
⌛ Starting corerp-cloud functional tests...
✅ corerp-cloud functional tests succeeded

@github-actions

github-actions Bot commented Aug 20, 2026 •

Copy link
Copy Markdown

Functional Tests - corerp-cloud

32 tests  ±0   31 ✅ +1   20m 36s ⏱️ + 1m 37s
 2 suites ±0    1 💤 ±0 
 1 files   ±0    0 ❌  - 1 

Results for commit 6d11be4. ± Comparison against base commit ab0a17a.

♻️ This comment has been updated with latest results.

@brooke-hamilton
brooke-hamilton added this pull request to the merge queue Aug 20, 2026
Merged via the queue into radius-project:main with commit 2ba622f Aug 20, 2026
83 of 86 checks passed

This branch was successfully deployed

1 active deployment
external-contributor-approval — 6d11be41 Deployed Aug 20, 2026 by pujitha24 via Approval Gate #12064
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:standard Ongoing maintenance, minor improvements, documentation updates, and routine development work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Recipe pack deploy with -g <group> resolves environment from default/workspace group and fails in target group

5 participants