directhex · April 15, 2015 10:04
diff --git a/gistfile1.txt b/gistfile1.txt
 0:57 <directhex> the problem is the ghprb relies on a magic github branch, which always contains master, plus at the tip, a single merge commit merging the pull request in question. refs/remotes/origin/pr/*/merge
 10:58 <directhex> now, that branch is recreated whenever a commit lands on the PR, *or* in master
 10:58 <directhex> so if i submit a PR, the tip of the merge branch might have commitid 1234567. then someone else pushes to master. now the tip of the merge branch has commit abcdefa - and 1234567 no longer exists, and has never existed.
 10:59 <kyllikki> directhex: so pull requests rebase every time? eww
 11:00 <directhex> when combining the pull request builder with a matrix job (to do tests on multiple arches), the matrix master determines the commitid, then the matrix slaves build that commitid when they finally run
 11:00 <directhex> which might take a while, for arches with contention (e.g. i only have 2 armhf builders)
 11:00 <directhex> by the time the job is scheduled/run, the commitid the slaves are scheduled to build may no longer exist
 11:00 <kyllikki> I see where this is going :-(
 11:01 <directhex> which causes https://jenkins.mono-project.com/job/test-mono-pull-request/775/label=debian-armhf/console
	0:57 <directhex> the problem is the ghprb relies on a magic github branch, which always contains master, plus at the tip, a single merge commit merging the pull request in question. refs/remotes/origin/pr/*/merge
	10:58 <directhex> now, that branch is recreated whenever a commit lands on the PR, or in master
	10:58 <directhex> so if i submit a PR, the tip of the merge branch might have commitid 1234567. then someone else pushes to master. now the tip of the merge branch has commit abcdefa - and 1234567 no longer exists, and has never existed.
	10:59 <kyllikki> directhex: so pull requests rebase every time? eww
	11:00 <directhex> when combining the pull request builder with a matrix job (to do tests on multiple arches), the matrix master determines the commitid, then the matrix slaves build that commitid when they finally run
	11:00 <directhex> which might take a while, for arches with contention (e.g. i only have 2 armhf builders)
	11:00 <directhex> by the time the job is scheduled/run, the commitid the slaves are scheduled to build may no longer exist
	11:00 <kyllikki> I see where this is going :-(
	11:01 <directhex> which causes https://jenkins.mono-project.com/job/test-mono-pull-request/775/label=debian-armhf/console