Closed ykuijs closed 1 month ago
@ykuijs Thanks for reaching out. I tested with removing the module dependency on v1.1 and it still works fine. As you might have read, the mentioned PR is the second iteration, based on a previous one. I think with the more robust version of iteration 2, the dependency mentioned for v1.1 isn't necessary anymore.
But could you elaborate a bit more on the pipeline you're using and maybe enable verbose logging? I'm wondering because if your pipeline is running in Windows PowerShell, then the dependency on v1.1 should already be fulfilled as it is default installed, and if you're running PowerShell 7, it should download v2.7 and not v1.1.
Installing M365DSC and all prerequisites can take 15 minutes to complete. When using Microsoft Hosted agents in Azure DevOps, this needs to be done for each deployment, which just adds 15 minutes to each deployment.
To speed up deployments, I am pre-downloading M365DSC and all of its prerequisites (using Save-Module) and creating a Zip file which a deployment can simply download and install. That only takes 2 minutes, which is much faster.
That prepare pipeline now fails because it is trying to download PSDesiredStateConfiguration v1.1. The error it is giving says that it cannot download that module, which of course makes sense because that does not exist in the PSGallery.
This also means it is useless to include it in the prerequisites because if for whatever reason the module isn't installed, it cannot be downloaded anywhere to resolve the issue.
15min? That's on good days :) I can say from experience that when I started doing this it took about 10min and eventually started increasing until one day I saw it took almost 1h so I started using Save-Module, that one as you say takes way less but for some reason it also started to increase the amount of time to retrieve the modules exponentially. I also use pipeline caching which helps here, but the first time always takes ages.
I just ditched all of that and now I'm using ModuleFast (https://github.com/JustinGrote/ModuleFast) which only takes a few seconds to download all dependencies.
The dependency on v1.1 was necessary at first to prevent the uninstallation of it when a newer version of PSDesiredStateConfiguration was available. That was one thing why the PR was reverted at first. But I guess we can remove it now since the handling was improved.
15min? That's on good days :) I can say from experience that when I started doing this it took about 10min and eventually started increasing until one day I saw it took almost 1h so I started using Save-Module, that one as you say takes way less but for some reason it also started to increase the amount of time to retrieve the modules exponentially. I also use pipeline caching which helps here, but the first time always takes ages.
I just ditched all of that and now I'm using ModuleFast (https://github.com/JustinGrote/ModuleFast) which only takes a few seconds to download all dependencies.
Totally agree with that. With the number of Graph modules increasing, the time required to install all dependencies is also increasing.
I have seen the ModuleFast module as well, that is also used in the Sampler framework. Unfortunately ModuleFast is requiring PSv7 and I am currently using PowerShell v5.1. Although I am looking at using PSv7 in the future.
The dependency on v1.1 was necessary at first to prevent the uninstallation of it when a newer version of PSDesiredStateConfiguration was available. That was one thing why the PR was reverted at first. But I guess we can remove it now since the handling was improved.
Perfect, I will remove the dependency in a PR I am working on!
Not wanting ti hijack this thread any further but the way I workaround that is just to use ModuleFast on a separate PS7 task (but same job), and run everything else on other tasks which run on PS5.1 instead.
Not wanting ti hijack this thread any further but the way I workaround that is just to use ModuleFast on a separate PS7 task (but same job), and run everything else on other tasks which run on PS5.1 instead.
That is a good alternative! Right now my priority is to release the new whitepaper with the current scripts, etc. But I will put this on the backlog for the next iteration!
Looking forward to the new whitepaper!
Description of the issue
In PR #4949 @FabienTschanz added the PSDesiredStateConfiguration v1.1 module as a required module, alongside with a requirement for v2.0.7 for PowerShell Core and later.
On Windows PowerShell v5.1 the PSDesiredStateConfiguration v1.1 module is always installed and we don't need that module for later versions of PowerShell.
The current requirement is causing issues in my pipeline, since it is trying to download v1.1 which does not exist in the PSGallery.
Is there a specific need for mentioning v1.1? If not, would it be an idea to remove that requirement?
Microsoft 365 DSC Version
Dev
Which workloads are affected
other
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version