A branch-update build and a pull-request build validate different things, so one build cannot generally satisfy both contexts:

• Branch update runs against the commit at the updated branch ref.
• Pull request open/update runs against OneDev's merge preview (the merge commit of the source and target branches) and records the pull request association used by the PR page and its required-build check.

This is why a build that appears in commit/build data is not accepted as the PR's current required build. The PR must use a build submitted for its merge ref; otherwise it could pass even though the source branch does not build after being combined with the target branch.

The usual configuration is therefore:

• Use the Branch update trigger only for branches that need validation outside a PR, typically long-lived branches such as main and release/**.
• Use the Pull request open or update trigger for feature branches via PRs, and list unit-tests under the target branch protection's Required Builds.

With non-overlapping scopes, a feature-branch push with an open PR produces one PR build, while a direct update to a protected/long-lived branch produces one branch build.

If every update of every feature branch must also be validated independently of any PR, then two builds are necessary when such a branch has an open PR: one validates the branch head and the other validates the PR merge preview. There is currently no safe way for a single run to represent both revisions.