Register-PSRepository in non-interactive mode?

[f0rt]

Team,
I'm using Register-PSRepository for automation on internal build system. On PS 5.1. the cmdlet prompts and I get the following message(from the build logs):

Exception calling "ShouldContinue" with "2" argument(s): "Windows PowerShell is in NonInteractive mode. Read and Prompt functionality is not available."

The cmdlet doesn't have -Force/-Confirm parameters and it doesn't respect the $ConfirmPreference variable. Is there a workaround for this?

Thanks,
Nedko

[bmanikm]

In automation scripts, please use the below command to bootstrap the NuGet provider.

Install-PackageProvider -Name NuGet -MinimumVersion '2.8.5.201' -Force

[godefroi]

@bmanikm That command doesn't seem to download nuget.exe. In my environment, I have been running that command, but I don't get the error about non-interactive mode until I get to the publish-module step, which fails because it's trying to prompt about downloading nuget.exe.

[bmanikm]

@godefroi Correct, Install-PackageProvider only installs NuGet provider, and it doesn't download nuget.exe. NuGet.exe is required only during Publish-Module or Publish-Script operations.

Please take a look at
https://github.com/PowerShell/PowerShellGet/blob/development/tools/build.psm1#L72 to understand the logic for bootstrapping NuGet.exe in automation scripts.

[Jaykul]

This is extremely unsatisfying. @bmanikm's suggestion results in downloading NuGet in every iteration/build/deployment!

We end up needing something like this in our deployment scripts?

if(!(Get-PackageProvider NuGet)) { 
   Install-PackageProvider Nuget -ForceBootstrap -Force
}

It's a bit frustrating that I need to write so many lines for that, and then I have the same problem when installing modules.

[bmanikm]

In automation scripts, please use the below simple command to bootstrap the NuGet provider. This bootstrap the NuGet provider only if it is not available on the local machine.

Get-PackageProvider NuGet -ForceBootstrap

[Vit0hA]

In non-interactive mode this step requires additional privileges, at least account under which is running this commandlet has to have SeAssignPrimaryTokenPrivileges and SeServiceLogonRight rights. I've just extended this script by adding SeAssignPrimaryTokenPrivilege options. Currently Register-PSRepository works fine for me from our Chef recipes.

[dmpe]

This should be reopened @bmanikm - I have similar use case with Docker (installing pswh on docker image behind proxies) and it would be very welcomed

[IOnine]

@bmanikm I am now also experiencing this issue, and it seems your suggestions have nothing to do with the actual problem. The problem is with using the Register-PsRepository cmdlet. NOT with installing the PackageProvider. This should definitely be re-opened and addressed appropriately.

See below my output:
[Step 2/4] VERBOSE: Registering Repository <obfuscated>
[Step 2/4] C:\<obfuscated>\temp\buildTmp\<obfuscated>.ps1 : Error was "Exception calling "ShouldContinue" with "2"
[Step 2/4] argument(s): "Windows PowerShell is in NonInteractive mode. Read and Prompt functionality is not available.""
[Step 2/4] + CategoryInfo : NotSpecified: (At Line: 4059 Char: 9:) [Write-Error], WriteErrorException
[Step 2/4] + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,<obfuscated>.ps1

[deadlydog]

I was having a similar issue when trying to run a PowerShell script in my release pipeline that needed access to a module in our private Azure DevOps Artifacts feed, so I was attempting to do:

Register-PSRepository -Name MyRepoName -SourceLocation 'https://pkgs.dev.azure.com/[MyOrganization]/_packaging/[MyFeed]/nuget/v2' -InstallationPolicy Trusted

Install-Package MyPrivatePowerShellModule -InstallUpdate -AllowClobber

However, when the script runs on the MS hosted agent, it ends up in an infinite wait loop outputting:

"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a_temp\527651b0-116e-46aa-a599-141b4dfc9899.ps1'"
Registering PSRepository
[Minimal] [CredentialProvider]DeviceFlow: https://pkgs.dev.azure.com/[MyOrganization]/_packaging/[MyFeed]/nuget/v2
[CredentialProvider]To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code EB64QSSD6 to authenticate.##[section]Starting: PowerShell Script

I came across this feedback post though and was able to get it working with the following code (ensuring $PersonalAccessToken contains a PAT with permissions to read from the provider):

$pat = ConvertTo-SecureString '$PersonalAccessToken' -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential 'Username@DoesNotMatter.com', $pat

Install-PackageProvider NuGet -Scope CurrentUser -Force > $null

if ($null -eq (Get-PSRepository -Name 'MyRepoName' -ErrorAction SilentlyContinue))
{ Register-PSRepository -Name 'MyRepoName' -SourceLocation 'https://pkgs.dev.azure.com/[MyOrganization]/_packaging/[MyFeed]/nuget/v2' -InstallationPolicy Trusted -Credential $credential }

Install-Module -Name 'MyPrivatePowerShellModule' -Repository 'MyRepoName' -Force -AllowClobber -Credential $credential
Import-Module -Name 'MyPrivatePowerShellModule' -Force

The trick was to first do Install-PackageProvider NuGet -Scope CurrentUser -Force, and then also to use Personal Access Token credentials. I hope this helps anybody else who stumbles across this issue.