#2680: sourcestamp merging with no changes uses revision of oldest instead of
newest
--------------------+------------------------
Reporter: brendan | Owner:
Type: defect | Status: new
Priority: major | Milestone: undecided
Version: 0.8.5 | Resolution:
Keywords: |
--------------------+------------------------
Changes (by dustin):
* cc: jaredgrubb (added)
Comment:
This really comes from the sorting in the buildrequests passed to the
Build constructor, with the earliest first. It then merges the remainder
with that one, and takes its sourcestamp.
The interesting bit is in the build request distributor, which calculates
the next build request and takes that as the first in the list. It relies
on the builder's nextBuild configuration, and if that's not set, chooses
"the first build" (in {{{_getNextUnclaimedBuildRequest}}}). And those
are, indeed, sorted by {{{submitted_at}}} in
{{{_fetchUnclaimedBuildRequests}}}.
So, this might actually be a regression with the introduction of the build
chooser stuff.
Jared, should {{{_getNextUnclaimedBuildRequest}} prefer the last, rather
than the first, of the unclaimed build requests by default?
--
Ticket URL: <http://trac.buildbot.net/ticket/2680#comment:1>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Buildbot-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/buildbot-commits
