Repository navigation
ci(help): analyze a folder of fixtures with Test-IntuneScript on Linux - #48
Merged
Merged
Conversation
The static analysis needs only the file, which makes it the one part of the module a Linux host can use, and nothing tested that: the help job imported the module and checked help. It now writes a remediation detection with return before exit 1 and a Win32 detection with nothing on stdout under the folder layout the suite template describes, runs Test-IntuneScript over the folder, and fails unless both errors are reported with the script type taken from the folder names.
fadwen
commented
Oct 19, 2026
fadwen
left a comment
Owner
Author
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| # file and nothing else. This step keeps that true. The script type is inferred from | ||
| # folder names, so the fixtures use the layouts the suite template describes, with the | ||
| # separators this host writes; the harness and the log readers stay Windows-only. | ||
| - name: Analyze scripts on Linux |
Owner
Author
There was a problem hiding this comment.
Placed in the help job rather than a job of its own because it is the same Ubuntu runner with the module already importable, and a separate job would add a runner for a 10-second check. Two fixtures rather than one so the folder-based inference is exercised: the Publish-Module rehearsal already covers the remediation case on Windows, and the Win32 folder is the path where a separator difference would show. Asserting on the IslAssumedContext message is what proves the type came from the folder and not from a default.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test-IntuneScriptis described as needing only the file, with no tenant and no elevation, which makes it the one part of the module a Linux host can use. Nothing tested that: thehelpjob, the only Linux job inquality-gates.yml, imported the module and checked help. A run on a Debian 13 host with PowerShell 7.4.4 showed the command works there, with the script type inferred from forward-slash folder paths and a folder search returning every script, so the job now checks it on every pull request.Changes
.github/workflows/quality-gates.yml,helpjob: a step writes two fixtures under a temporary folder,Remediations/Widget/Detect.ps1with areturnbeforeexit 1andWin32/Widget/Detect.ps1withexit 0and nothing on stdout, runsTest-IntuneScriptover the folder, and fails unless theIslExitCodeIssueerror, theIslOutputIssueerror and anIslAssumedContextnote namingWin32Detectionare all reported. The fixtures mirror the oneBuild/Publish-Module.ps1analyzes in the staged module, plus the Win32 case that exercises folder-based inference.CLAUDE.md: thehelpjob's description says what now runs on Linux and what still does not.CHANGELOG.md: Changed entry under Unreleased.Verification
Notes