[OpenWrt-Devel] Proposal: change buildbot's build failure logic to be less restrictive regarding packages from feeds
hannu.nyman at iki.fi
Wed Jan 21 13:15:07 EST 2015
We have seen several times in the past few months that one non-essential
package from feeds fails to build and stops the whole buildbot build.
Yesterday it was "ola" from packages feeds, and in the past few months at
least "python" from packages and "ltq-vmmc" from telephony have done the same.
It seems crazy to me that non-essential packages from feeds, which by
definition are non-essential, can kill the whole buildbot build for a platform.
Normally a failing package gets marked "broken", but the build still
continues. However, some packages from feeds seem to kill the whole build
when they fail.
As far as I have been able to determine, if the failing package contains
either a kernel module (kmod) or a "host section", then the failure of that
package is considered so essential that the whole builbot build is halted.
The package is not just classified as "broken package", but the whole build
is really stopped.
I understand that a host section breakage from a tool, toolchain component or
a core package in the main Openwrt repo may be reason enough to halt the
build. Same goes for a kmod.
But when that failure happens to a package from e.g. telephony feed, I do not
really understand why the whole buildbot build needs to be halted. The more
we have packages maintained in Github by a large group of people, the more we
will have this kind of accidental breakages by small non-essential packages.
I propose that devs would change the buildbot build failure logic so that the
failing packages from the feeds would not kill the whole build. Failing
packages from feeds should just me marked as broken. That might require
splitting "package compilation" step 25 to two different steps, one for
packages from the Openwrt main repo, one for packages from feeds. (or
alternatively, the essential packages should contain an ESSENTIAL definition
on the Makefile, or something like that, and the failure logic should take
that into account.)
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel