Current behavior (context)

On an open pull request page today:

• A play button already appears next to required jobs that have not run yet. It submits the job against the merge preview commit (merge ref), not the source branch tip.
• The jobs status strip lists builds tied to the PR’s current build commit (also merge-oriented). It does not offer a general “run any job” action.
• Manual runs against a branch/commit already exist elsewhere (Builds page, commit detail, build spec view).

So the gap looks less like “no run control on the PR page” and more like “no non-intrusive way from the PR page to run a job against the source branch.”

Clarifying questions

Please answer with the letter options (and notes if useful).

1. Primary goal of running on the source branch (vs today’s merge-commit run)?

   • A. Reproduce branch-update CI (same as pushing to the source branch)
   • B. Debug/test a job quickly without waiting for merge-preview verification
   • C. Support jobs that must not use a merge commit (e.g. publish/deploy from the feature branch)
   • D. Something else (please describe)

2. Where should the control live, while staying non-intrusive?

   • A. Extend the existing per-job play control (required-jobs area / job status chips) with a source-branch option
   • B. Add a single low-emphasis “Run job…” entry near existing PR operations, reusing the Builds-page job picker
   • C. Only expose run-on-source when opening an existing job status dropdown on the PR
   • D. Deep-link/outlink to commit or Builds page for the source tip (no new PR-page control)

3. Which jobs should be runnable from that UX?

   • A. Only jobs already shown on the PR (required / currently listed)
   • B. Any job defined in the build spec at the source tip
   • C. A configurable allow-list (e.g. via build spec or project setting)

4. Should a manually launched source-branch build be associated with the open PR?

   • A. Yes — show it in the PR jobs/status area like other PR builds
   • B. No — treat it as a normal branch build; PR page stays merge-verification focused
   • C. Associate only when the user explicitly opts in

5. For pull requests from forks, which project/ref should the job run against?

   • A. Source project + source branch (true fork branch build)
   • B. Target project + PR head/merge refs only (keep today’s trust/permission model)
   • C. Source-branch run only when source and target are the same project; otherwise keep merge-ref behavior

6. Who should be allowed to trigger it?

   • A. Same as today’s manual job permission (run job)
   • B. Also allow users who can modify the PR (as with the existing required-job play button)
   • C. Stricter: code write on the source branch / project

Pros / cons (brief) and recommendation

Recommendation: start with 2B + 3B + 4B + 5C + 6A unless question 1 is mainly merge-verification recovery (then improve discoverability of the existing merge play button instead of adding source-branch runs).

That keeps PR merge checks authoritative, reuses the existing manual-run UI, and only special-cases same-project source branches where permissions/trust already match branch builds.

A play button already appears next to required jobs that have not run yet. It submits the job against the merge preview commit (merge ref), not the source branch tip.

Perhaps this required jobs is the divergence between current behaviour and what I am seeking. I don't see a play button on the pull request page, e.g., https://code.kelsiem.io/<parent-project>/<project>/~pulls/<number>

1. C is my best guess - I can confirm this behavior is on a feature branch
2. in .submission (CSS) on the side panel, below the sourch branch
3. B. Using standard existing behavior/rules.
4. A. Very helpful to know which PR triggered it. Bonus points for being able to navigate from the build/pipline/job to the PR that initiated it. Pros and Cons? Your recommendation? Advise and then ask @robin .
5. A. Pros and Cons? Your recommendation?
6. A

Bear in mind I'm getting confused with what you are referring to as a merge-verification run...am I missing something that already exists?

Recommended approach B appeals best to me.

Thanks — that helps a lot. You’re not missing a hidden control: if you don’t see a play button on the PR page, that’s expected in many setups.

What “merge-verification run” means (and why the play button may be absent)

Today the PR page is mainly about whether the PR is safe to merge into the target branch, not about running jobs on the feature branch tip.

1. OneDev computes a merge preview commit (refs/pulls/<n>/merge) = target tip + source tip (as the chosen merge strategy would produce).

2. Required jobs (branch protection / build requirement) are evaluated against that merge context. Jobs marked * in the side panel Jobs list are those required jobs once builds exist.

3. A play control appears only in the top summary warning for required jobs that do not yet have a current build, and only when a merge preview exists. It runs the job against the merge preview commit / merge ref, with the build linked to the PR. If:

   • the project has no required jobs for the PR, or
   • those jobs already have current builds, or
   • merge preview isn’t available yet,

   then no play button is shown. The side-panel Jobs strip itself is status/history only — it has no general “run job” action.

So the gap you hit is real: there is currently no PR-page control to launch an arbitrary job against the source branch tip (which matches goal 1C). Manual runs still exist on the Builds page / commit detail, but not from this PR UX.

Captured preferences

Approach B (dedicated low-emphasis “Run job…” near Source) still looks like the right UX shape for 1C + 3B.

4. Associate source-branch runs with the open PR?

Recommendation: lean A for linkage/navigation, but keep merge gates authoritative:

• Store the PR on the build (and link build → PR) so the side panel / build detail can show “initiated from PR #…”.
• Do not treat these source-branch builds as satisfying required jobs, and do not overwrite the PR’s merge-check build commit when launching them.
• Optionally list them under Jobs with a clear “source branch” label, separate from merge-check status.

@robin — does that split (associate for UX/traceability, isolate from merge requirements) match what you’d want, or prefer full 4B / opt-in 4C?

5. Forks: where should the job run?

Recommendation: ship C first (same-project source-branch runs from the PR side panel). That delivers 1C for normal feature branches without changing fork trust semantics. If true fork source builds are required later, treat them as a follow-up with explicit rules for project, secrets, and who may trigger.

Happy to adjust 4/5 once Robin weighs in; implementation can stay deferred until those calls are settled.

LGTM

No response required by AI user.

Closing as the clarifying Q&A is agreed (LGTM).

@servicedesk what I meant is that recommendation C looks good to me. Please create an issue for this.

Closing; implementation tracked in issue #2911.

@zaakiy Created issue #2911 for the agreed design: side-panel Run job… against the source branch tip for same-project PRs (recommendation C), with PR association for traceability but isolated from merge-requirement accounting. Linked as related.