Repository navigation
Replace Pester submodule with import #1371
Description
Activity
It's not going to work on non-windows without additional changes.
This is post-Aug17 release item.I can't see the submodule's repository yet, but happy to take a look and see what changes need to be made in Pester once I've got access.
Reacted by sergeiDave Wyatt (@dlwyatt) done!
Working on it, should have something ready soon.
I'm really not a fan of reading
${directorySeparatorChar}all over the place, so I'm doing that a different way. In most places, I'm just using/instead of\(if it works fine on Windows anyway), and in some cases, using a new proxy function of Join-Path with nicer syntax for joining multiple path parts, like so:<# The "Ex" naming is stupid; I just want something to make it clear in the calls to this function that it's _not_ the original Join-Path cmdlet (and doesn't need to be guarded with $SafeCommands.) The difference is that ChildPath is now an array with ValueFromRemainingArguments defined, so we can do this: Join-PathEx One Two Three Four Five However, we've removed pipeline input support from the ChildPath parameter, as a tradeoff. #> function Join-PathEx { [CmdletBinding()] param( [Parameter(Mandatory = $true, Position = 0, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true)] [Alias('PSPath')] [string[]] ${Path}, [Parameter(Mandatory = $true, Position = 1, ValueFromRemainingArguments = $true)] [AllowEmptyString()] [AllowNull()] [string[]] ${ChildPath}, [switch] ${Resolve}, [Parameter(ValueFromPipelineByPropertyName = $true)] [pscredential] [System.Management.Automation.CredentialAttribute()] ${Credential} ) begin { $null = $PSBoundParameters.Remove('Path') $null = $PSBoundParameters.Remove('ChildPath') $combinedChildPath = '' if ($ChildPath.Count -gt 0) { $combinedChildPath = $ChildPath[0] for ($i = 1; $i -lt $ChildPath.Count; $i++) { $combinedChildPath = & $SafeCommands['Join-Path'] -Path $combinedChildPath -ChildPath $ChildPath[$i] @PSBoundParameters } } } process { $null = $PSBoundParameters.Remove('Path') $null = $PSBoundParameters.Remove('ChildPath') foreach ($p in $Path) { & $SafeCommands['Join-Path'] -Path $p -ChildPath $combinedChildPath @PSBoundParameters } } }
Describe 'Stripping common parent paths' { $paths = @( Join-PathEx C: Common Folder UniqueSubFolder1 File.ps1 Join-PathEx C: Common Folder UniqueSubFolder2 File2.ps1 Join-PathEx C: Common Folder UniqueSubFolder3 File3.ps1 ) $commonPath = Get-CommonParentPath -Path $paths $expectedCommonPath = Join-PathEx C: Common Folder It 'Identifies the correct parent path' { $commonPath | Should Be $expectedCommonPath } $expectedRelativePath = Join-PathEx UniqueSubfolder1 File.ps1 It 'Strips the common path correctly' { Get-RelativePath -Path $paths[0] -RelativeTo $commonPath | Should Be $expectedRelativePath } }
Dave Wyatt (@dlwyatt) backward slashes should no longer be an issue, we recently made PowerShell on Linux slash agnostic (with the caveat that literal backslashes in file paths are not yet supported).
Ah, even better. That accounts for most of the differences between Pester and the psl-Pester fork. :) Thanks!
Just about ;) And thank you!
James Truher (@JamesWTruher) mentioned that Add-Type is also coming (or already there), so there's not much that needs to be done here. I've just opened a PR for Pester (pester/Pester#589) which should be all we need to support backslashes, I think.
The only other big change I see between the psl fork is that the Invoke-PesterInJob function was completely rewritten to use in-proc runspaces instead of
Start-Job. Is this becauseStart-Jobis or was not available yet in Open PS? If so, I can copy that code over as well. (Should give us a slight performance boost anyway, getting rid of the overhead of starting a new process.)Dave Wyatt (@dlwyatt) any updates here?
Also, would you like to be assigned to this issue?
When I went through the code differences, they seemed to be lumped into three categories: slashes, Add-Type, and Start-Job. I believe the first two are already fixed in PS, but Start-Job may not be working yet on Linux. (Pester itself doesn't actually need it, but it's used in some of the test suite.)
So basically, download the latest Pester on a Linux build, run it and see what happens :)
OK, will do
Adding #1979 for cross-reference
2 remaining items
For #1979, we're going to remove the Pester submodule and rely on importing Pester.
Maintainers are assigning this over to James Truher (@JamesWTruher) for investigation.
Dave Wyatt (@dlwyatt) I'm finally looking at this now - is there a specific branch I should be validating against? Running against 3.4.6 is failing about 7% of the tests
James Truher (@JamesWTruher) as far as I can tell, we already removed the Pester submodule from the repository. Is this item now implicitly to use the latest version of Pester from the Gallery in our tests? If so, can we change the title to that effect and move this out to 6.1.0 (unless you see a reason for us to be on 3.4.6)?
- modified the milestones: ,
on May 23, 2017 Based on an offline conversation with James Truher (@JamesWTruher), while we should do this, we should hold this work off until Pester is fully cross-platform (which will likely not happen until after we release a stable 6.0.0).
Aditya Patwardhan (@adityapatwardhan) Should we close the Issue too after #6064?
Per #1275 we need to test if we can use the Pester package and remove the submodule. Failing that, we will likely move it to a vendor folder.