Bug fixes for running a large/complicated solution on AL-Go

[freddydk]

❔What, Why & How

This PR fixes a few minor bugs and 3 major, all changes required for moving Bunker Holding Group to AL-Go for GitHub

[Bug] Fix a small spelling mistake in DownloadProjectDependencies.Action.ps1‎

[Bug] Avoid failing entire workflows due to cleanup issues (f.ex. if no Container is used) in PipelineCleanup.ps1

Fixes #2086 - In AL-Go-Helper.ps1

The sort order is changed from this:

to this:

Which completes in 2:01, saving 45 minutes from the first run, just by re-ordering and allowing people to see compile errors up-front - fail early!
The key difference here is just the order in which projects are built/tested. In the first run, build3 had to wait 30 minutes until the test run was done before building the next jobs, and 1 hour and 44 until the last build jobs would run.
In the second run - all test jobs are running in parallel at the very end, getting compile errors quicly and postponing test runs until the very last.

Subsequently, when using GitHub hosted Custom runners, we can achieve this:

Note that the custom runners are running tests in 40 minutes, where the GitHub hosted runners takes 104 minutes. This is because the GitHub hosted custom runners are using SQL Server Developer edition and no docker.

Saving a full 2 hours, bringing a complete build from 2 hours 46 minutes down to 46 minutes.

Fixes #2085 - In GetDependencies in GitHub-Helper.ps1

When downloading artifacts from projects build earlier in the same workflow, it flags projects as missing if either Apps or TestApps are missing. This means that projects, which only contains TestApps or Apps will be downloaded but also looked for in the last known good build later on. It doesn't fail, because it cannot find the artifacts in that built either.
See https://github.com/Freddy-DK/DependenciesProblems/actions/runs/21079606240/job/60630194330

Fixes #2084 in GetArtifactsFromWorkflowRun in GitHub-Helper.ps1

If a build is cancelled during tests or failing due to instability - and you subsequently re-run failed jobs (not all jobs) you will get multiple artifacts for succeeding projects and subsequent jobs cannot locate these artifacts (they get an array of artifacts). The "double" artifacts are not visible in the UI, but found when artifacts are queried. You could see this as a bug in GitHub, but we should fix this in AL-Go in a way that works, even if GitHub fixes their bug.

This build: https://github.com/Freddy-DK/DependenciesProblems/actions/runs/21090442931
Has double artifacts: https://api.github.com/repos/Freddy-DK/DependenciesProblems/actions/runs/21090442931/artifacts

When than downloading artifacts from prior builds for incremental builds, it fails with

throw "Multiple artifacts found with mask $artifactMask for project $projectName"

See: https://github.com/Freddy-DK/DependenciesProblems/actions/runs/21090506962/job/60661024240

✅ Checklist

• Add tests (E2E, unit tests)
• Update RELEASENOTES.md
• Update documentation (e.g. for new settings or scenarios)
• Add telemetry

[freddydk]

@microsoft-github-policy-service agree

[freddydk]

@microsoft-github-policy-service agree

[freddydk]

There is something wrong with your @microsoft-github-policy-service agree thingy - I am constantly asked to agree with this - it doesn't make any sense

[mazhelez]

PR looks good.
Left minor comments about naming, doc and test.

It isn't clear why adding the branch filter when getting workflow run artifacts is needed.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[freddydk]

@microsoft-github-policy-service agree

[aholstrup1]

A new version of AL-Go (v8.2) has been released.

Please move your release notes changes to above the ## v8.1 section in the RELEASENOTES.md file.

This ensures your changes are included in the next release rather than being listed under an already-released version.