On Mon, Nov 06, 2006 at 10:16:01AM +0100, Adrian Schröter wrote:
Am Sunday 05 November 2006 08:41 schrieb Steve Beattie:
I've noticed this a few times now: I'll commit an update to a package (via osc if that matters) and then go to the website to watch the build progress for that package. If it happens to be a point where the buildservice is relatively idle, the package will usually have started rebuilding against all of the repositories I've assigned.
On multiple occasions I've gone to view a build log for the package, catching it in progress. I'll watch it continue building to completion, only to discover at the end that it just rebuilt the *previous* version of the package, If I then go back to the package status page, the package will have had a new build kicked off for the same repository target; returning to the log, it will indeed be a build for the newly committed version of this package.
Is this known behavior? Expected behavior? Please let me know if there's anything in the above that I need to clarify.
This can happen, when the client is changing something (lets say some unimportant file) and commits right afterwards, instead of submitting all other changes before.
However, I think that osc does handle this in the right way already, so it should not happen using it.
Peter, is this true ?
In former times, each commit would trigger a rebuild, which would invalidate (kill) ongoing build jobs. Wouldn't it? Has this changed? If new builds are scheduled behing ongoing builds, that would explain the behaviour (which I have been seeing myself a lot as well). Although I (so far) claimed that build jobs aren't just done twice, but even more often. If "obsolete" build jobs are not (no longer?) killed: what's the rationale? Regards, Peter -- SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo: Research & Development A malevolent monster (not true?); Some mischief microbic; What makes someone phobic; The work one does not want to do. From: Chris Young (The Omnificent English Dictionary In Limerick Form)