Am Tuesday 07 November 2006 17:30 schrieb Marcus Schäfer:
Hi,
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?
I have seen the same. If you change for example the spec file twice times with "osc ci" commands in between I can see how the build is scheduled -> building -> scheduled -> building. But each build runs until it's finished.
right, build job killing is not yet implemented. Independend from that, I think the commit needs anyway to be atomar for all changes. Because you want to see later which files/changes did happen with one commit. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org