bootstrap --wait can time out before a matching CI run is detected

[adampoit]

Summary

In Patchlane 0.4.1, patchlane bootstrap --wait can time out waiting for CI even though GitHub creates a matching run for the exact published sync SHA. This happened twice while bootstrapping a fork.

Observed behavior

Patchlane published sync/integration, printed:

Waiting for 'CI' to test 11a9bcee40afe792121dcc1364a104910bbd1002.

and then exited non-zero with:

Timed out waiting for 'CI' to start for 11a9bcee40afe792121dcc1364a104910bbd1002.

The matching run existed and eventually passed:

• Run: https://github.com/adampoit/taskwarrior-tui/actions/runs/29632242209
• Workflow: CI
• Branch: sync/integration
• Head SHA: 11a9bcee40afe792121dcc1364a104910bbd1002

Afterward, the equivalent lookup returned that run successfully:

gh run list \
  --workflow CI \
  --branch sync/integration \
  --commit 11a9bcee40afe792121dcc1364a104910bbd1002 \
  --limit 1 \
  --json databaseId \
  --jq '.[0].databaseId'

This occurred on two separate published SHAs. The first matching run was https://github.com/adampoit/taskwarrior-tui/actions/runs/29631944248.

Expected behavior

bootstrap --wait should tolerate normal GitHub Actions event-delivery latency and continue once the matching run appears. If CI passes, it should promote the exact tested SHA.

Current limitation

waitForCiRun() polls 24 times at five-second intervals, giving GitHub a fixed two-minute window:

patchlane/src/bootstrap.ts

Lines 14 to 42 in 91c58fd

	return new Promise((resolve) => setTimeout(resolve, milliseconds));
	}
	async function waitForCiRun(ciWorkflow: string, syncBranch: string, syncSha: string, cwd: string) {
	for (let attempt = 0; attempt < 24; attempt++) {
	const result = run(
	'gh',
	[
	'run',
	'list',
	'--workflow',
	ciWorkflow,
	'--branch',
	syncBranch,
	'--commit',
	syncSha,
	'--limit',
	'1',
	'--json',
	'databaseId',
	'--jq',
	'.[0].databaseId',
	],
	cwd,
	);
	if (result.status === 0 && result.stdout) return result.stdout;
	await delay(5_000);
	}
	throw new Error(`Timed out waiting for '${ciWorkflow}' to start for ${syncSha}.`);

That window appears too short in practice, and there is no timeout override or polling progress.

Suggested improvements

• Increase the default startup timeout, perhaps to 10 minutes.
• Make the timeout and polling interval configurable through CLI options or environment variables.
• Perform a final lookup before reporting a timeout.
• Include the workflow, branch, SHA, repository, and attempted query in the timeout error.
• Consider querying Actions runs directly by head_sha and event, rather than depending only on workflow-name resolution.
• Print periodic progress so a delayed run is distinguishable from a malformed query.

The safe workaround was to verify the exact successful run and invoke patchlane promote --expected-sync-sha=<SHA> manually.