Support trackALAlertsInGitHub for workspace compilation build path - #2331
Support trackALAlertsInGitHub for workspace compilation build path#2331aholstrup1 wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Extends GitHub AL alert tracking to workspace compilation.
Changes:
- Adds compiler capability detection and
--errorlogdirectoryforwarding. - Connects alert settings to workspace builds.
- Adds Pester coverage and release notes.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
Actions/.Modules/CompileFromWorkspace.psm1 |
Adds error-log support and capability probing. |
Actions/CompileApps/Compile.ps1 |
Configures the diagnostics output directory. |
Tests/CompileFromWorkspace.Test.ps1 |
Tests error-log argument construction. |
RELEASENOTES.md |
Announces workspace compilation alert support. |
Thread an ErrorLogDirectory through Build-AppsInWorkspace and CompileAppsInWorkspace so that, when trackALAlertsInGitHub is enabled with workspaceCompilation, altool workspace compile writes per-project *.errorLog.json diagnostics into .buildartifacts/ErrorLogs (the same folder the classic Run-AlPipeline path uses). Defensively probes 'workspace compile --help' and only passes --errorlogdirectory when supported. Adds Pester coverage. AB#641509
9e442bc to
16c5653
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
Actions/.Modules/CompileFromWorkspace.psm1:476
- A failed native executable does not throw solely because it exits nonzero, so this
catchdoes not reliably detect a failed help probe. If the failed invocation emits usage text containing the option, this returnstrueand the subsequent compile can hard-fail instead of taking the promised warning/fallback path. Check$LASTEXITCODEbefore matching the output (or invoke throughRunAndCheck, which already enforces this).
$compileHelp = & $ALToolPath workspace compile --help 2>&1 | Out-String
return ($compileHelp -match [regex]::Escape($Option))
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
Actions/.Modules/CompileFromWorkspace.psm1:476
- The compatibility probe runs a native executable but never checks
$LASTEXITCODE. On Windows PowerShell 5 and default PowerShell 7 behavior, a non-zero native exit is not guaranteed to entercatch, so failed help probes can still be parsed as successful output instead of taking the intended unsupported-compiler fallback. Capture and check the exit code immediately after invocation and return$falsefor any non-zero result.
$compileHelp = & $ALToolPath workspace compile --help 2>&1 | Out-String
return ($compileHelp -match [regex]::Escape($Option))
Actions/.Modules/CompileFromWorkspace.psm1:466
- This new function has no direct Pester coverage: all three added tests mock it, so the actual help-output matching and failed-probe fallback are never exercised. Add
InModuleScopetests for supported output, unsupported output, and a failed/non-zero invocation.
function Test-ALToolWorkspaceCompileSupportsOption {
Test-ALToolWorkspaceCompileSupportsOption ran 'altool workspace compile --help' but never checked \0. A native executable does not throw on a non-zero exit, so a failed probe whose output happened to contain the option name would be treated as supported and the subsequent compile could hard-fail instead of taking the warn-and-skip fallback. Now returns false on any non-zero exit. Adds direct Pester coverage (supported output, unsupported output, and failed probe) via a controllable fake altool script.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Suppressed comments (1)
Actions/.Modules/CompileFromWorkspace.psm1:366
- The added tests invoke
CompileAppsInWorkspacewithErrorLogDirectorydirectly, so they do not verify this newBuild-AppsInWorkspaceforwarding path or thetrackALAlertsInGitHubsetting that supplies it. The existing workspace-compilation E2E scenario also neither enables the setting nor asserts an ErrorLogs artifact, despite the PR checklist claiming E2E coverage. Please add a forwarding unit test and update the E2E scenario to exercise the user-facing path.
ErrorLogDirectory = $ErrorLogDirectory
❔What, Why & How
trackALAlertsInGitHubsurfaces AL compiler diagnostics as GitHub code scanning alerts, but it only worked on the classic Run-AlPipeline build path. WhenworkspaceCompilation(preview) was enabled, no*.errorLog.jsonfiles were produced, so no alerts appeared even with the setting turned on.This wires the same behavior into the workspace compilation path. When both
trackALAlertsInGitHubandworkspaceCompilationare enabled, AL-Go passes--errorlogdirectorytoaltool workspace compileso each project emits an*.errorLog.jsondiagnostics file into its.buildartifacts/ErrorLogs/folder. From there the existing upload +ProcessALCodeAnalysisLogspipeline picks them up, converts them to SARIF, and publishes code scanning alerts, matching the classic build behavior.The
--errorlogdirectoryargument is threaded through via aGenerateErrorLogswitch driven by$settings.trackALAlertsInGitHub. If the consumed compiler version does not yet support--errorlogdirectory, the option is skipped and a warning is logged so the rest of the build is unaffected (no silent no-op, no hard failure).✅ Checklist