I am finishing setting up a PowerShell Module and I have set a series of 5 Pester tests that pass locally but not on GitHub actions. I wonder that may be due to restrictions on the creation of files or folders in the workflow...
In the tests, temporary env files and folders are created to simulate the loading and unloading of env. vars, for example:
Describe "Import-DotEnv" {
Context "Loading environment variables" {
It "Loads environment variables from a .env file" {
# Create a temporary .env file
$tempDir = New-Item -ItemType Directory -Path "$env:TEMP\ImportDotEnvTest_$(Get-Random)"
$envFilePath = Join-Path $tempDir.FullName ".env"
Set-Content -Path $envFilePath -Value "TEST_VAR=123"
try {
# Change to the directory containing the .env file
Set-Location -Path $tempDir
# Assert that TEST_VAR is set to "123"
$env:TEST_VAR | Should -Be "123"
}
finally {
# Reset the working directory
Set-Location -Path $env:TEMP
# Clean up
Remove-Item -Path $tempDir.FullName -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path Env:\TEST_VAR -Force -ErrorAction SilentlyContinue
}
}
}
And the resulting workflow output at GH actions is:
Run powershell -ExecutionPolicy Bypass -Command "Invoke-Pester -Path .\Tests\ -Output Detailed"
Pester v5.7.1
Starting discovery in 1 files.
Discovery found 5 tests in 850ms.
Running tests.
Running tests from 'ImportDotEnv.Tests.ps1'
Describing Import-DotEnv
Context Loading environment variables
Error: [-] Loads environment variables from a .env file 1.5s (1.27s|232ms)
Message
Context Unloading environment variables
Error: [-] Unloads environment variables from a .env file 12ms (9ms|3ms)
Message
Context Handling multiple .env files
Error: [-] Loads and unloads multiple .env files correctly 24ms (14ms|10ms)
Message
Context Edge cases
[+] Does not throw an error if the .env file does not exist 115ms (112ms|3ms)
Error: [-] Handles empty .env files correctly 100ms (99ms|1ms)
Message
Tests completed in 5.83s
Tests Passed: 1, Failed: 4, Skipped: 0, Inconclusive: 0, NotRun: 0
So my question is why would it work locally and not on GH actions? More information can be found here: https://github.com/CosmicDNA/ImportDotEnv/actions/runs/13348899375/job/37282823873
I later found out the problem was associated with running the tests on Powershell 5.1 where RelativeBasePath is not yet available...
The RelativeBasePath parameter became available from PowerShell 7.4 onwards. On Windows PowerShell (5.1) (which is based on .NET Framework) instead of PowerShell Core (which is cross-platform and based on .NET Core), the RelativeBasePath parameter is not supported.
As in Windows PowerShell, there isn't a direct way to specify a relative base path using Resolve-Path since this functionality was introduced in PowerShell Core. I had to instead look for using a different approach by manually calculating the relative path. This change was done and fixed it on the following commit: https://github.com/CosmicDNA/ImportDotEnv/commit/4fedd5fcfad3d81d3f9a2160b37222d95bdcf2ea
Basically implementing a Get-RelativePath as follows:
function Get-RelativePath {
param (
[string]$Path,
[string]$BasePath
)
# Cache the directory separator
$separator = [System.IO.Path]::DirectorySeparatorChar
# Resolve absolute paths
$absolutePath = [System.IO.Path]::GetFullPath($Path)
$absoluteBasePath = [System.IO.Path]::GetFullPath($BasePath)
# Split paths into segments
$pathSegments = $absolutePath -split [regex]::Escape($separator)
$basePathSegments = $absoluteBasePath -split [regex]::Escape($separator)
$commonLength = (
0..([math]::Min($pathSegments.Length, $basePathSegments.Length) - 1)
).Where({ $pathSegments[$_] -eq $basePathSegments[$_] }).Count
# Calculate the relative path using list comprehension
if ($commonLength -eq 0) {
# No common base path, return the full path
return $absolutePath
}
else {
# Use list comprehension to build the relative path
$relativePath = @(".") + ($pathSegments[$commonLength..($pathSegments.Length - 1)])
}
# Join the segments into a relative path
$relativePath = $relativePath -join $separator
return $relativePath
}
Then I took the opportunity to make it compatible with PowerShell 5.1 while keeping the hyperlink functionality and avoiding ANSI color escape coding...