Fix dependency resolution when branch name contains ']' character#2313
Open
aholstrup1 wants to merge 1 commit into
Open
Fix dependency resolution when branch name contains ']' character#2313aholstrup1 wants to merge 1 commit into
aholstrup1 wants to merge 1 commit into
Conversation
GetDependencies enumerated the resolved dependency folder with Get-ChildItem -Path, which treats ']' (allowed in git branch names) as a wildcard metacharacter and returns the folder itself instead of the contained .app files. This caused 0 apps to be published. Use -LiteralPath since the folder is already resolved.
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request fixes a PowerShell wildcard edge case in AL-Go’s dependency resolution for thisBuild dependencies: when a resolved dependency folder path contains a ] (legal in git branch names), Get-ChildItem -Path can treat it as a wildcard pattern and return the folder itself instead of enumerating its .app files.
Changes:
- Update
GetDependenciesto enumerate resolved dependency folders usingGet-ChildItem -LiteralPathto avoid wildcard interpretation. - Add a regression test covering dependency folder paths containing
]and asserting the.appfiles are returned. - Document the fix in
RELEASENOTES.md.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| Tests/GitHub-Helper.Test.ps1 | Adds regression coverage for dependency folder paths containing ], ensuring .app files are correctly enumerated. |
| RELEASENOTES.md | Notes the dependency resolution fix for branch names containing ]. |
| Actions/Github-Helper.psm1 | Switches dependency folder enumeration from -Path to -LiteralPath to prevent wildcard matching on ]. |
mazhelez
approved these changes
Jul 10, 2026
spetersenms
approved these changes
Jul 10, 2026
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.
❔What, Why & How
Branch names can legally contain a
]character (git forbids[but allows]), for example a mangled[master]tag left over asmaster]. When such a branch's build-project dependencies are downloaded, the artifact folder name embeds that]. InGetDependencies(thethisBuildpath inGithub-Helper.psm1), the already-resolved dependency folder was enumerated withGet-ChildItem -Path $folder.-Pathtreats]as a wildcard metacharacter, so instead of listing the.appfiles inside the folder it returned the folder itself as a single match. That folder path was then added to the downloaded-apps list and "published" as if it were an app, resulting in 0 apps actually installed (Installing apps took 0 seconds) and downstream failures.The fix uses
-LiteralPathinstead of-Path.$foldercomes fromGet-Item $downloadNameand is already a fully resolved directory path, so there is never a reason to re-interpret it as a wildcard. For any path without[/]the two are identical, so existing behavior is unchanged; the only difference is that bracket-containing paths now enumerate their.appfiles correctly.Verified against a real failing microsoft/BCApps CI run (the log printed the folder, not the
.appfiles, as "found from previous job") and reproduced/covered with a regression test.✅ Checklist