Repository navigation
fix(gate): leave the contents of a Win32 Package folder out of a folder search - #40
Conversation
…er search The gate analyzed every .ps1 under the script folders, including the contents of a Win32 app's Package folder, the files that become the .intunewin. An install.ps1 there runs through the install command as SYSTEM, but nothing in its name tells the analysis that, so it was read as a user-context 32-bit platform script and its machine-wide writes became warnings that failed the build at -FailOn Warning. Files under a Package segment are left out of a folder search, next to *.Tests.ps1. A Packages folder, which holds Win32 apps, stays in, and a file named directly on -Path is still analyzed.
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| Where-Object { $_.Name -notlike '*.Tests.ps1' } | ForEach-Object { $_.FullName } | ||
| Where-Object { | ||
| $_.Name -notlike '*.Tests.ps1' -and | ||
| "$($_.DirectoryName)\" -notmatch '(?i)[\\/]Package[\\/]' |
There was a problem hiding this comment.
The separator is appended so a Package folder that is the file's own parent matches too: DirectoryName ends in '\Package' with nothing after it, and the pattern needs a separator on both sides to reject 'Packages' and 'MyPackage'. The class accepts both slashes so the same line holds on a Linux runner.
| [System.IO.File]::WriteAllText((Join-Path $script:Scripts 'Win32\Widget\Package\install.ps1'), | ||
| "New-Item -Path HKLM:\SOFTWARE\Widget -Force | Out-Null`r`nexit 0`r`n", $utf8Bom) | ||
| [System.IO.File]::WriteAllText((Join-Path $script:Scripts 'Packages\Gadget\Detect.ps1'), | ||
| "Write-Output 'installed'`r`nexit 0`r`n", $utf8Bom) |
There was a problem hiding this comment.
Kept clean on purpose. Its first version returned before exit 1 and carried an error-level finding, and 'Packages/Gadget' sorts before 'Remediations/Widget', so it became the first error annotation and the earlier test's assertion on that line failed. A clean Win32 detection still appears in the output through its IslAssumedContext line, which is all the new test needs.
Summary
Examples/Invoke-IntuneScriptGate.ps1analyzed every.ps1under the script folders, including the contents of a Win32 app'sPackagefolder (Win32\<app>\Package\, the files that become the.intunewin, whereExamples/IntuneScripts.Tests.ps1.templateexpects them). Aninstall.ps1there is run by the agent through the install command as 64-bit SYSTEM, but nothing in its name or folder tells the analysis that, so it fell to the portal default for an unnamed script: a user-context, 32-bit platform script. Every machine-wide write in the installer became anIslContextIssuewarning, withIslArchitectureIssuewarnings forHKLM:\SOFTWAREand$env:ProgramFileson top, and the build failed at-FailOn Warningfor findings that do not apply to an installer.This is the same shape as the Pester-suite problem fixed in #38, and it is fixed in the same place: the gate's folder search.
Changes
Examples/Invoke-IntuneScriptGate.ps1: a folder search leaves out files under aPackagesegment, alongside*.Tests.ps1. Only the singular segment is matched: aPackagesfolder is one that holds Win32 apps (the script-type inference treats it as a Win32 folder hint), and the detection scripts under it stay in. A file named directly on-Pathis still analyzed. The-Pathhelp says so.Examples/intune-script-gate.ymlandREADME.md: theSCRIPT_PATHScomment and the gate paragraph name both exclusions.Tests/Integration/ScriptGate.Tests.ps1: the fixture gainsWin32\Widget\Package\install.ps1(a machine-wide write) andPackages\Gadget\Detect.ps1(clean); the new test checks the installer is absent from a folder run and analyzed when named, and that thePackagesdetection is still reported.CHANGELOG.md: Fixed entry under Unreleased.Verification
Tests/Integration/ScriptGate.Tests.ps1: 9 passed on PowerShell 7.6.6 and on Windows PowerShell 5.1..ps1files; no line over 115 characters.Intune\Win32\Widget\Package\install.ps1that writes toHKLM:\SOFTWAREandProgram Files: before the change the installer carried 3IslContextIssueand 3IslArchitectureIssuewarnings and-FailOn Warningfailed; after it the installer is absent from the output.Notes
Test-IntuneScript, so the command's behaviour on a folder (every.ps1) is unchanged; the gate is what knows the suite template's layout.