Use a folder based manifest discovery vs PATH based manifest discovery
Summary of the new feature / enhancement
The current documentation ( https://learn.microsoft.com/en-us/powershell/dsc/resources/concepts/anatomy?view=dsc-3.0) appears to indicate that DSC will do manifest discovery on any valid path. I would recommend instead taking a page from Terraform's playbook and only do manifest discovery recursively from the calling folder. This has several benefits including: 1. Allows different teams to develop and run their manifests independently on the same build system, 2. Makes troubleshooting easier by limiting manifests to a known location, and 3. Potentially limits unknown or bad behavior if someone inadvertently leaves a manifest file in images or builds that is accessible from a PATH location.
Proposed technical implementation details (optional)
- Keep the DSC executable in the PATH so it can be called from the manifest location
- During configuration deployment, CD to the folder where the desired manifest file resides
- call DSC config from there
DSC will
- Recurse the folder and subfolders for manifest files
- Build it's graph of dependencies
- Build the resources from the discovered files.
@jchancellor-ms - I think this is mostly handled by the DSC_RESOURCE_PATH environment, as covered in the CLI documentation, in terms of limiting the search path explicitly. The implementation is definitely different, but I think it covers points 1--3 you raised:
- Different teams can set the environment variable before calling
dscto isolate their resource usage. - The limited path defined by the variable limits the manifests to specified locations.
- Only manifests in the specified path are discovered.
I'll definitely get the anatomy concept doc updated to mention the environment variable.
DSC_RESOURCE_PATH is a way to override the current default behavior. The default behavior is to search PATH env var because the goal is that in the future, exes you would have on the system would also be DSC resources. For example, winget.exe should itself be a DSC resource as well as ipconfig.exe. In this way, the resource manifest would reside with the exe rather than defining a specific location for the manifests.