[Contribution Process Bug]: Incremental builds never engage on PRs — modified files are diffed against the last main build instead of the PR merge-base

[JesperSchulz]

Describe the issue

A pull request that changes no AL code at all triggers a full build of every country and build mode (~50 build jobs, hours of CI).

Incremental builds are already enabled for pull requests in .github/AL-Go-Settings.json:

"incrementalBuilds": {
  "onPush": false,
  "onPull_Request": true,
  "onSchedule": false,
  "mode": "modifiedApps"
}

They don't take effect, because the "modified files" set is computed against the last successful main build rather than against the pull request's merge-base. Any commit that landed on main in between is attributed to the pull request.

Concrete evidence from #10491, which changes exactly two files (CODEOWNERS and docs/process/ReviewRouting.md), run 32469944841:

Using head SHA 6186e26da6317a46f9876bf839e8d90826ade753 from pull request
This is a pull request, but baseline SHA was specified to aa44cfcfe4cb7b1db94285c365f22a8f44aae2c3
git diff --name-only aa44cfcfe4cb7b1db94285c365f22a8f44aae2c3 6186e26da6317a46f9876bf839e8d90826ade753
Modified files:
- CODEOWNERS
- docs\process\ReviewRouting.md
- src\Apps\W1\SalesOrderAgent\app\.resources\Prompts\SalesOrderAgent-AgentInstructions.json
- src\Layers\W1\BaseApp\Foundation\Reporting\CompositeLayoutLookupHelper.Codeunit.al
- src\Layers\W1\BaseApp\Foundation\Reporting\HeaderFooterThemeAssignment.Page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\LayoutThemeandHeaderFooter.Page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\ReportLayoutFactBox.Page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\ReportLayoutNewDialog.page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\ReportLayouts.page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\ReportThemeandHeaderFooter.Page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\TenantReportLayoutCfg.Page.al
- src\Layers\W1\BaseApp\Foundation\Reporting\ThemeandHeaderFooterBox.Page.al
- src\Layers\W1\Tests\Report\CompositeLayoutTests.Codeunit.al

##[notice]Changes to D:\a\BCApps\BCApps\src\Layers\* detected, building everything

Only the first two lines belong to the pull request. The other eleven come from #10134 and #10457, which merged into main after the chosen baseline:

$ git log --oneline aa44cfcf..28e273dd     # baseline .. true merge-base
28e273ddbd [Bug 646487] Composite layout: focus fix, body-layout gating, and setup UI (#10134)
81f4674418 Show price calculation error assistance when Available Only is off (#10457)

Those eleven files include src/Layers/W1/BaseApp/..., which matches src/Layers/* in fullBuildPatterns, so the run escalates to "building everything".

Diffing against the pull request's actual merge-base gives the correct answer:

$ git merge-base origin/main HEAD
28e273ddbd161a8d9ff56884f0604876585aa8a6

$ git diff --name-only 28e273ddbd161a8d9ff56884f0604876585aa8a6 HEAD
CODEOWNERS
docs/process/ReviewRouting.md

Neither path matches any entry in fullBuildPatterns, and neither belongs to an app — so nothing needed to be built.

The busier main is, the worse this gets: the baseline drifts further behind, so the odds that some unrelated commit touched src/Layers/* approach certainty. In practice this means incremental builds almost never engage on pull requests, which is consistent with what we see day to day.

Expected behavior

A pull request that touches no AL code, no ruleset and no build infrastructure should not build any app.

More generally, the decision of what a pull request changed should be based on the pull request's own diff (merge-base..head), so that unrelated commits already merged to main are never attributed to it — and in particular never trigger fullBuildPatterns.

Note there is a real subtlety worth deciding deliberately: the baseline SHA also selects which previous build's artifacts can be reused. Reusing artifacts from a baseline older than the merge-base is genuinely unsafe, so the two concerns may need to be separated:

• What did this PR change? → evaluate against merge-base..head (drives fullBuildPatterns and modified-app detection).
• Which artifacts can be reused? → keep using the baseline build SHA, or advance the baseline to the newest successful build at or after the merge-base.

Conflating the two is what produces the current behaviour.

Steps to reproduce

1. Wait for a build of main to succeed; note its SHA as the baseline.
2. Let at least one pull request touching anything under src/Layers/ merge into main afterwards.
3. Open a pull request that changes only a non-AL file (for example CODEOWNERS, or a file under docs/).
4. Look at the Initialization job, groups Get Modified Files and Determine Incremental Build.

Observed: the modified-file list contains files from the other pull requests, and the run reports Changes to src\Layers\* detected, building everything. All country × build-mode jobs run.

Expected: the modified-file list contains only the files in this pull request, and no app is built.

Additional context

• Example pull request: Simplify CODEOWNERS to a flat team block and stop requesting the org team on every PR #10491 (2 files changed: CODEOWNERS, docs/process/ReviewRouting.md)
• Example run: https://github.com/microsoft/BCApps/actions/runs/32469944841
• Baseline used: aa44cfcfe4cb7b1db94285c365f22a8f44aae2c3 ("Restore AL0424 to Warning in the base ruleset (Restore AL0424 to Warning in the base ruleset #10470)", 2026-08-21 09:01)
• True merge-base: 28e273ddbd161a8d9ff56884f0604876585aa8a6
• Relevant settings in .github/AL-Go-Settings.json: incrementalBuilds, fullBuildPatterns
• The logic lives in the AL-Go actions DetermineProjectsToBuild / GetModifiedFiles (pinned at 992ee305e2c6d86d85d53e18c4fc88a5171a8cd4 in .github/workflows/PullRequestHandler.yaml), so the fix may belong in AL-Go rather than in this repository. Raising it here first so the BCApps impact is recorded.

Cost of the current behaviour: every documentation-only, CODEOWNERS-only or workflow-adjacent pull request pays a full multi-hour matrix build, which also consumes runner capacity that real product changes are queuing for.

Internal Work Item: AB#647482

[JesperSchulz]

Tracked internally as AB#647482 (Dynamics SMB \ Cloud and AI Platform \ Engineering Systems), related to AB#640966.