Skip to content

Conversation

@andyleejordan
Copy link
Member

PR Summary

Since we no longer expect DSC to ingest ARMv2 as generated by Bicep (in favor of Bicep invoking DSC resources via the gRPC extension), we can remove this unfinished work that simply got our demos running again.

PR Context

This deserialization approach was a cheap workaround, we had not yet revisited the design to properly support symbolic names (such as fixing resource IDs, dependency resolution, etc.).

We also don't need to add the Bicep emitted fields that we were just skipping.

Since we no longer expect DSC to ingest ARMv2 as generated by Bicep
(in favor of Bicep invoking DSC resources via the gRPC extension),
we can remove this unfinished work that simply got our demos running again.

This deserialization approach was a cheap workaround,
we had not yet revisited the design to properly support symbolic names
(such as fixing resource IDs, dependency resolution, etc.).

We also don't need to add the Bicep emitted fields that we were just skipping.
@andyleejordan
Copy link
Member Author

This is a revert of #1210, but with merge conflicts resolved, and still-relevant tests kept. We can also close #1221 and #1223. I would strongly encourage we remove the copy() (loop) implementation and rely on higher-order tooling for complex resource orchestration.

@andyleejordan andyleejordan marked this pull request as ready for review January 14, 2026 23:41
@Gijsreyn
Copy link
Contributor

@andyleejordan - isn't the copy() functionality a v1 feature?

@andyleejordan
Copy link
Member Author

@andyleejordan - isn't the copy() functionality a v1 feature?

🤷 as far as I could tell it was a lot of hassle for little if any gain as it was really to support for loops that came from Bicep. We don't necessarily need to do that in DSC-native configs, but it's just a suggestion from me and not relevant to this PR (except that I removed the part of the copy() test dealing with symbolic names).

@Gijsreyn
Copy link
Contributor

@andyleejordan - isn't the copy() functionality a v1 feature?

🤷 as far as I could tell it was a lot of hassle for little if any gain as it was really to support for loops that came from Bicep. We don't necessarily need to do that in DSC-native configs, but it's just a suggestion from me and not relevant to this PR (except that I removed the part of the copy() test dealing with symbolic names).

Thanks for the explanation, Andy, and I get that part indeed. Symbolic names are more towards v2 (or even are). There might be other ways to loop for sure, but I can't think of any atm.

Copy link
Collaborator

@michaeltlombardi michaeltlombardi left a comment

Choose a reason for hiding this comment

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

Code changes look good to me - I think there's still some open questions on impact to other functionality (copy loops), but I prefer that functionality be pushed to higher order tools (bicep, a DSC config builder in PowerShell, whatever) instead of being inherent to the engine / configuration document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants