Setup: A repo with multiple VCS-connected workspaces, each scoped to its own directory via trigger patterns (e.g. workspace A → /dirA/**/*, workspace B → /dirB/**/*).
What happens: When a PR’s feature branch contains a Merge branch 'main' into <feature> commit, merging that PR triggers runs in workspaces whose directories the PR never actually changed. The trigger reason shown is “File change detected in tracked directory” and the resulting plan is empty (0 to add, 0 to change, 0 to destroy).
Cause I traced: HCP Terraform appears to count the diff of the merge commit toward trigger-pattern matching. The Merge branch 'main' into <feature> commit’s first-parent diff lists every path that was already on main but not yet on the branch — i.e. changes that are already applied. Those paths match other workspaces’ trigger patterns, so those workspaces are triggered even though the PR’s net diff (base…head) does not touch them.
Confirmed it’s the merge commit, not net-zero changes: A control test — committing a change to dirB/ and then reverting it on the branch (net-zero, no merge commit) — does not trigger workspace B. So the trigger is specifically tied to the merge commit’s diff, not to any change that nets to zero.
Why this matters: These are wasted runs. They consume our limited monthly run/apply quota and add noise, and they defeat the purpose of trigger patterns (scoping a workspace to its own directory). Net diff (which the VCS API readily provides) would not include these already-applied paths.
Question: Is this intended behavior, or a bug? If intended, what’s the rationale, and is the recommended workaround to use squash merges (which keep intermediate merge commits out of the push)?
I also opened a docs-clarification issue for the behavior: Docs: clarify that a merge commit's diff counts toward trigger-pattern matching, causing empty-plan runs on unrelated workspaces · Issue #2698 · hashicorp/web-unified-docs · GitHub