ci: let the build be started by hand, not only by a pull request

[TheMeinerLP]

Why

Build PR triggered on pull_request alone, and that was the only path to a build.

On 2026-08-02 at 21:07 UTC, 272cb0b3 (#41) landed on main and put FalcoLightingChunk.java into conflict with feat/block-storage. GitHub cannot form refs/pull/N/merge for a conflicted PR, and without a mergeable state no run is created at all — not failed, not skipped, absent. PRs #39 and #40 sat without CI for fifteen hours, and nothing on the Actions page said why. The only workflow carrying workflow_dispatch was Benchmark, so there was no way to ask for a build and watch it refuse.

A manual trigger does not fix a conflict. It makes the state visible instead of silent.

What changed

on: [pull_request] becomes pull_request plus workflow_dispatch, and the reusable workflow gets force-build tied to the event:

force-build: ${{ github.event_name == 'workflow_dispatch' }}

The reusable workflow decides whether to build from a dorny/paths-filter comparison, and that comparison has no base outside a pull request. A run somebody started by hand is one they want regardless of what changed, so it skips the filter rather than depending on whatever the filter answers without a base. On a pull_request event the expression is false and the path filter keeps deciding exactly as it does today — this PR changes nothing about automatic runs.

Not verified, and why it cannot be from here

GitHub reads workflow_dispatch only from the default branch. The button does not appear for this workflow until this is on main, so the manual path cannot be exercised from the branch. After merging, worth checking once:

• Run workflow appears for Build PR and accepts a non-default branch
• Detect changes completes rather than erroring without a base
• Build (…) runs on all three runners despite code=false — that is force-build doing its job
• an ordinary PR still behaves as before: on a docs-only change the build is still skipped by the path filter

If Detect changes errors instead of returning false, force-build will not save the run, because build needs changes and has no always(). In that case the fix belongs in the org workflow, not here.

[github-actions]

Test results

  201 files    201 suites   3m 50s ⏱️
  683 tests   683 ✅ 0 💤 0 ❌
2 058 runs  2 058 ✅ 0 💤 0 ❌

Results for commit 33aa82e.