Hi all,
I've expected this before and now it has actually happened: a patch that was verified by jenkins caused a build failure after being merged by gerrit. Let's be aware of the possibility of this happening:
Commit [1] changed the rcv_rach() signature and correctly fixed all callers. Commit [2] added a new caller of rcv_rach(), with the correct, old arguments.
Both tested successfully on their own, and were accepted for merge. [2] was merged first, thus [1] no longer edited all callers as would have been necessary.
One way to catch this: gerrit could run another jenkins build every time when we hit the Submit button and 'master' has already moved on. Not sure if this is easily achievable.
The other way to catch this are the regular (non-gerrit) jenkins builds on http://jenkins.osmocom.org/jenkins . Maybe selected jobs could send failure reports to the noisy gerrit mailing list...
Another way we would see this is as soon as another patch is rebased onto master, or when testing locally, obviously.
Thanks for your attention,
~Neels
[1] "Change interface in osmo-pcu for 11 bit RACH" 959d1dee67e1c6fcfc57b347be2fb7a2ed099b2d
[2] "EGPRS: PUAN encoding: add test case to show wrong urbb_len issue" 02352b487ac6808b6adb8e8623f0921aad7f02d7
On 29 Aug 2016, at 11:41, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Hi all,
Hi!
I've expected this before and now it has actually happened: a patch that was verified by jenkins caused a build failure after being merged by gerrit. Let's be aware of the possibility of this happening:
Commit [1] changed the rcv_rach() signature and correctly fixed all callers. Commit [2] added a new caller of rcv_rach(), with the correct, old arguments.
Both tested successfully on their own, and were accepted for merge. [2] was merged first, thus [1] no longer edited all callers as would have been necessary.
it happens. One option is to wait after the rebase. It should trigger a new build but is not too convenient.
holger