Skip to content

New-GitHubRepository: Exception When Specifying the WhatIf Parameter #197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
X-Guardian opened this issue May 29, 2020 · 3 comments · Fixed by #213
Closed

New-GitHubRepository: Exception When Specifying the WhatIf Parameter #197

X-Guardian opened this issue May 29, 2020 · 3 comments · Fixed by #213
Labels
bug This relates to a bug in the existing module. in progress Work on this issue is already underway. Please don't work start new work on it.

Comments

@X-Guardian
Copy link
Contributor

Issue Details

When calling the New-GitHubRepository function and passing the WhatIf standard parameter, the following output and exception is returned:

What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Start-Job" on target "Invoke-GHRestMethod-132352403347195287".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
Telemetry is currently enabled.  It can be disabled by calling "Set-GitHubConfiguration -DisableTelemetry". Refer to USAGE.md#telemetry for more information. Stop seeing this 
message in the future by calling "Set-GitHubConfiguration -SuppressTelemetryReminder".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Start-Job" on target "Get-NugetPackage-132352403347470221".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
Telemetry is currently enabled.  It can be disabled by calling "Set-GitHubConfiguration -DisableTelemetry". Refer to USAGE.md#telemetry for more information. Stop seeing this 
message in the future by calling "Set-GitHubConfiguration -SuppressTelemetryReminder".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Start-Job" on target "Get-NugetPackage-132352403348269899".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
What if: Performing the operation "Output to File" on target "\\nas01\data\users\simon\documents\PowerShellForGitHub.log".
ConvertFrom-Json: C:\Program Files\WindowsPowerShell\Modules\PowerShellForGitHub\0.13.1\GitHubCore.ps1:334:43
Line |
 334 |              $finalResult = $finalResult | ConvertFrom-Json
     |                                            ~~~~~~~~~~~~~~~~
     | Cannot bind argument to parameter 'InputObject' because it is null.

Code to reproduce the issue

New-GitHubRepository -RepositoryName $RepoName -OrganizationName $OrgName -WhatIf

Operating System

OsName               : Microsoft Windows Server 2019 Standard
OsOperatingSystemSKU : StandardServerEdition
OsArchitecture       : 64-bit
WindowsVersion       : 1809
WindowsBuildLabEx    : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

PowerShell Version

PSVersion                      7.0.1
PSEdition                      Core
GitCommitId                    7.0.1
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Module Version

ModuleType Version    PreRelease Name
---------- -------    ---------- ----             
Script     0.13.1                PowerShellForGitHub
@HowardWolosky HowardWolosky added the bug This relates to a bug in the existing module. label May 31, 2020
@HowardWolosky
Copy link
Member

Thanks for the report, @X-Guardian. Will look into it today.

As an aside, I really like (and appreciate) the format of your bug reports, and I'd like to standardize on something close to it for a bug reporting template.

Can you provide/verify the commands you're running for each section so that I can put the directions in the template? I believe you're doing something like:

Operating System

Get-ComputerInfo | Select-Object OSName, OSOperatingSystemSKU, OSArchitecture, WindowsVersion, WindowsBuildLabEx, OSLanguage, OsMuiLanguages

I want to try to get something that will work a bit better cross-platform. The best I've been able to come up with so far is [System.Environment]::OSVersion which provide significantly less detail (for instance, no language info)

PowerShell Version

$PSVersionTable

Module Version

(Get-Module PowerShellForGitHub) | Select-Object Name, Version, PreRelease, ModuleType

@X-Guardian
Copy link
Contributor Author

Hi @HowardWolosky, I used a variation of the DscCommunity issue template which also has comment blocks to help people fill in the template.

There is also a good Pull Request Template complete with a task list.

No easy way of getting good OS detail cross-platform yet. Loads of people have been asking for Get-ComputerInfo to be included in PowerShell Core!
$PSVersionTable shows OS and platform detail in version 6 and above now, so you get some detail from that.

To get the module details, I would suggest adding the -ListAvailable parameter, in case the user doesn't have the module loaded.

@X-Guardian
Copy link
Contributor Author

With regard to the ShouldProcess handling, I would suggest having the check around the call to Invoke-GHRestMethod/Invoke-GHRestMethodMultipleResult rather than deeper into the code, as this will make the code much simpler. I think most cmdlets don't do anything cleverer than this.

HowardWolosky added a commit to HowardWolosky/PowerShellForGitHub that referenced this issue Jun 1, 2020
WhatIf support has now been simiplified in all API's that eventually
call into `Invoke-GHRestMethod`.  There's now a single check at the
top of that function which checks if it should continue or not.  If it
shouldn't, it early returns in order to avoid any code that might access
uninitialized content from outside of the ShouldProcess blocks later on.

Resolves microsoft#197
@HowardWolosky HowardWolosky added the in progress Work on this issue is already underway. Please don't work start new work on it. label Jun 1, 2020
HowardWolosky added a commit that referenced this issue Jun 1, 2020
WhatIf support has now been simiplified in all API's that eventually
call into `Invoke-GHRestMethod`.  There's now a single check at the
top of that function which checks if it should continue or not.  If it
shouldn't, it early returns in order to avoid any code that might access
uninitialized content from outside of the ShouldProcess blocks later on.

Resolves #197
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This relates to a bug in the existing module. in progress Work on this issue is already underway. Please don't work start new work on it.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants