dispatch-target

Demo: workflow_dispatch-triggered build that posts status + a PR comment back to its caller. Stand-in for orca-setup.

The companion repo is mporter/dispatch-source — read its README first for the full architecture, token setup, and end-to-end test procedure.

Workflow

.gitea/workflows/build-from-pr.yml takes four inputs from workflow_dispatch:

Input	Description
pr_number	PR number on the source repo
pr_head_sha	SHA at the PR head
pr_head_ref	Ref name at the PR head
source_repo	Source repo (owner/name)

The job currently echoes the inputs as a placeholder for a real build. It always runs a final feedback step (if: always()) that:

1. POSTs a commit status (success/failure) to ${source_repo}/statuses/${pr_head_sha} so the source PR's check turns green/red and links back to this run.
2. POSTs a comment to ${source_repo}/issues/${pr_number}/comments so the PR conversation gets a one-line "build success/failure — run log".

Both calls use ${{ secrets.DISPATCH_TOKEN }}.

Priming

Before the dispatch API will accept calls to this workflow, run it once manually from the Actions tab. Use these placeholders:

Input	Value
pr_number	1
pr_head_sha	0000000000000000000000000000000000000000
pr_head_ref	priming
source_repo	mporter/dispatch-source

The feedback step will fail (no such SHA / PR exists on dispatch-source). That is expected and harmless — the goal is only to register the workflow with the API so subsequent programmatic dispatches succeed.

Promoting to production

When porting to orca/orca-setup, replace the placeholder echo step with the real build flow. After actions/checkout of orca-setup, pin the meta-orca submodule (or whisk layer) to the PR head:

cd layers/meta-orca   # adjust to actual path
git fetch origin "refs/pull/${{ inputs.pr_number }}/head"
git checkout "${{ inputs.pr_head_sha }}"

then run the existing init-build-env flow. The feedback step needs no changes — it already targets ${{ inputs.source_repo }} (which will be orca/meta-orca in production).