The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item that's missing a doc string, hence breaking the openbsc build (which actually checks the doc strings unlike the libosmocore build job).
I pushed the fix I734b22c950242541322e902887bf779c14ba10fd and things should light up "green" (aka blue) again.
BTW, in a RL discussion lynxis suggested that it would be good if libosmocore commits were also checked against breaking openbsc. A point against it is that often something in libosmocore is changed and requires a follow-up in openbsc -- if the libosmocore build rejects commits that break openbsc, it would make it impossible to get these changes in. The workaround could be to have a secondary build job that merely comments on gerrit whether the openbsc build still works, without having -V voting powers.
Anyway, so far I think it is sufficient to catch these hopefully few cases once the regular master build on jenkins.osmocore.org goes up red, like now.
~N
Hi Neels,
On Sun, Dec 11, 2016 at 02:02:33AM +0100, Neels Hofmeyr wrote:
The libosmocore commit aa00f99be2e4cc64ede20d8c9548b83054696581 adds a VTY item that's missing a doc string, hence breaking the openbsc build (which actually checks the doc strings unlike the libosmocore build job).
Sorry for that. And thanks for the clean-up.
Anyway, so far I think it is sufficient to catch these hopefully few cases once the regular master build on jenkins.osmocore.org goes up red, like now.
yes, still it's sad. I am wondering what else we could do. Maybe include an executable / test case that can verify the documentation strings inside libosmocore itself?
I think specifically regarding vty documentation strings, this is not the first time we have seen this problem.