New-WinGetSource does not work due to missing template files #175
Comments
|
I've been spending a lot of time looking through the pipeline YAML files, and there's a lot that's done there that's not done when building locally. These steps are critical for the cmdlets to actually work. I'll add more details as I continue to work through this. |
|
After spending many hours working on this, I was unsuccessful in getting the automated approach to work and just finally went with a completely manual approach as outlined in the new-winget-rest-source-azure.md document. This isn't only a doc issue, there's bugs in the cmdlet itself and there's files (such as asp.json) that are missing completely. |
|
Hi @ameltzerMSFT, we appreciate the feedback on your experience. I will be looking through your different Issue's that you've logged from your experience and see what we can do to improve upon the experience. |
|
Thanks! I was trying to get this to work building/running from source versus trying the released module which may be in a different functional state. |
|
The PowerShell Module has a dependency on a HelperLib file that is used by another section of code in the project. So, to ensure the experience is shared across two separate tools we include a copy of the HelperLib in the Released PowerShell Module. Sorry for the confusion when trying to use the PowerShell scripts. |
I downloaded the last release and followed the step by step many times, but I still get the issue, it asks for a manifestCacheEndPoint value and when looking at the PS C:\> New-WinGetSource -Name "jmrestsource" -ResourceGroup "WinGet" -Region "northeurope" -ImplementationPerformance "Demo" -ShowConnectionInstructionswConnectionInstructions
WARNING:
The "Demo" build creates the Azure Cosmos DB Account with the "Free-tier" option selected which offset the total cost. Only 1 Cosmos DB Account per tenant can make use of this.
True
cmdlet Test-AzResourceGroupDeployment at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
manifestCacheEndpoint:
PS C:\> $Error
Test-AzResourceGroupDeployment: C:\Users\juanserv\Downloads\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\Test-ARMTemplate.ps1:44
Line |
44 | … rceResult = Test-AzResourceGroupDeployment -ResourceGroupName $Resour …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Cannot retrieve the dynamic parameters for the cmdlet. Cannot find path
| 'C:\Users\juanserv\Downloads\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\ARMTemplate\asp.json' because it does not exist.
Get-AzResourceGroup: C:\Users\juanserv\Downloads\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\Add-AzureResourceGroup.ps1:62
Line |
62 | … $Result = Get-AzResourceGroup -Name $Name -ErrorAction SilentlyCont …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 9:23:36 AM - Provided resource group does not exist.
Get-Process: A positional parameter cannot be found that accepts argument 'Get-ChildItem'.But if I look into the generated Parameters file, there's an asp.json file there: ls .\Parameters\
Directory: C:\temp\Parameters
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1/31/2023 9:32 AM 214 applicationinsights.json
-a--- 1/31/2023 9:32 AM 375 asp.json
-a--- 1/31/2023 9:32 AM 729 azurefunction.json
-a--- 1/31/2023 9:32 AM 928 cosmosdb-sql-container.json
-a--- 1/31/2023 9:32 AM 400 cosmosdb-sql.json
-a--- 1/31/2023 9:32 AM 1609 cosmosdb.json
-a--- 1/31/2023 9:32 AM 679 keyvault.json
-a--- 1/31/2023 9:32 AM 346 storageaccount.jsonShould the command be run in a specific path? I downloaded the latest script version in 1.1.20230126 and my current versions are: PS C:\> $PSVersionTable.PSVersion
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 3 2
PS C:\> (get-module Az).Version
Major Minor Build Revision
----- ----- ----- --------
9 3 0 -1
PS C:\> (get-module Microsoft.WinGet.Source).Version
Major Minor Build Revision
----- ----- ----- --------
0 1 0 -1And if I just ignore the errors, some resources are deployed, but the Function App is missing: |
|
Managed to beat the powershell azure setup scripts into submission and have some step-by-step instructions for usage of that and upload of package afterwards. https://github.com/gunnim/winget-restsource HTH ! |
After manually working around the issues in #171, #172, #173, and #174 I attempted to install a new WinGetSource per the documentation. It failed at multiple points, each which required manual workarounds. Even after spending hours on this it's still not able to run successfully end to end. I'll continue to update this Issue as I work through these things to document progress.
I attempted to run the cmdlet using the following syntax:
new-wingetsource -name winget -ResourceGroup WinGetTest -SubscriptionName "SUBSCRIPTION_NAME" -Region westuswhich failed without much useful text. Verbose logging also wasn't super helpful:The text:
Contains hints, but nothing actionable. There were no warnings or errors output to the console (which I later learned is because
-ErrorAction SilentlyContinueis used liberally throughout the code which means failures are hidden unless you dig for them).Even though errors were suppressed, they were still stored in
$Errorfor further inspection:This actually has some really useful information. Indeed, there is no
%REPOROOT%\Tools\PowershellModule\src\Library\ARMTemplatepath that's been created, which is why these things are silently failing.Looking through the repo sources, I found what appears to be all the necessary JSON templates under
%REPOROOT%\src\WinGet.RestSource.Infrastructure\Templates. I copied all these files to%REPOROOT%\Tools\PowerShellModule\src\Library\ARMTemplateand flattened them into a single directory.On re-run, the script got further (partial output):
I debugged into Test-ARMTemplates and discovered that the generated
%REPOROOT%\Tools\PowerShellModule\src\Parameters\azurefunction.jsonfile was missing a bunch of required data:Ignoring these caused a failure in creating the function. Setting these to empty or dummy values proceeded further, which then failed at the
aspstep:Looking through the entire repo, there doesn't appear to be any asp.json template file.
Ignoring this, the cmdlet then failed at creating the KeyVault because it already existed in some other Azure subscription.
There's no way in the cmdlet to work around this, so I had to re-run with an entirely new -Name parameter to something that I could ensure would be globally unique for KV creation.
After all this the script finally ran to completion (after prompting me 2 more times for the missing azurefunction.json template parameter values) with these immediate issues apparent:
%REPOROOT%\Tools\PowershellModule\src\Library\RestAPI\WinGet.RestSource.Functions.zipfile was not present.Looking through the entire repo including built files, there is no WinGet.RestSource.Functions.zip file. There is no mention in the README.md about how to create this file.
Current Status
I will continue working on this and update this Issue as I progress.I've given up on the automation and have instead gone with manual installation as outlined in the new-winget-rest-source-azure.md document. Even after multiple attempts to get the automation to run successfully by fixing bugs, fixing templates, and attempting to add the missing asp.json template, the creation of resources was ultimately incorrect and unusable.
Summary
To summarize, when trying to follow the documentation and run this cmdlet I've run into the following problems:
The text was updated successfully, but these errors were encountered: