This means the source mirror check is run a significant time after the source mirror
update allowing the mirroring code to have time to take effect rather than showing
errors on first build runs.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nextWorker can block a request if there is no worker available.
_getNextUnclaimedBuildRequest will always return the first request
which then will always fail to find worker, and this will block the queue
We therefore randomise the build requests queue with nextBuild to avoid
blocking.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The readme suggests exporting this variable from the
environment to expose multiple configuration JSON files
but the intended behavior doesn't work without adding the
variable to extra_env.
Signed-off-by: Thomas Goodwin <btgoodwin@geontech.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reduces unnecessary properties being set in builds where we don't need
them by filtering to the list of repos the build really needs.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change enables the children jobs to inherit the build
property from nightly scheduler. Build property inherits
yocto release, milestone and rc number from parent job.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This corresponds to the poky branch being used by default so its easier
for users to tell the builds apart and know which ones they are.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want seperate log files in the UI for each of the build steps. This
changes buildbot to monitor the command.log.X files which run-config
generates. It also searches the log output for errors and warnings and
summarises these neatly in the UI.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The got_revision trick, whilst quite neat, doesn't quite work and is a bit of
a hack breaking other buildbot internals. It gets et late in the builds leaving
a confusing build display in the meantime.
Use a dedicated property to store the "Yocto" build revision instead. This
property will be used by our own custom console UI.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means the display will show the correct revision before triggering and waiting
for all the builds to complete making the display less confusing.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the releases subdirectory to the release publishing destination path.
Signed-off-by: Graydon, Tracy <tracy.graydon@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, since the yocto-autobuilder-helper repository is the only
one that buildbot actually checks out in a step, the revision of that is
the one that gets associated with the build; however, it's much more
useful to have the revision set to the poky revision, so add a step that
does that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you can't clobber the build directory, check out the helper source
or unpack the repos successfully there's really not much point in
continuing, so stop the build immediately if they fail.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various errors resulted from not having been able to test the initial
implmentation of get_publish_dest():
* incorrect logic to determine whether a build was a release
* passing a filename rather than a string representing file contents to
json.loads()
* missing parameter on a call to buildbot's IProperties.setProperty()
Further we update the properties passed to the triggered builds via the
Trigger build steps to include the deploy_artefacts and publish_destination
properties.
This patch is able to succesfully supply required information for the
helper scripts to publish artefacts.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Based on the SetDest step in the old codebase this function is used to
determine where the artefacts of a build should be published. In order to
avoid overwriting previously published content the function keeps a list of
destinations which have already been created and written to on the
controller and avoids reusing them.
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
