Am Freitag, 29. November 2013, 10:36:38 schrieb Josef Reidinger:
On Thu, 28 Nov 2013 18:32:56 +0000 Susanne Oberhauser-Hirschoff <froh@suse.com> wrote:
Stephan Kulow <coolo@suse.de> writes:
The build server is what it says: a *build* server.
We use it as an integration server, quite successfully, and it comes close, but it is not explicitely targeted at integration.
So it is missing a few features to better support integration:
* Tools like git support 'merge' tracking of changes in branches back to mainline and from progress in mainline back to the branch. This then also allows to bisect regressions to the integration issue.
+1, I really miss some features from git and easy merging is one of it.
a git backend is there, but not finished. git can not replace our source server entirely due various issues, but we could offer also to store sources in a git repo on the server.
* Integration means testing, and testing may be a gate/decision point whether further builds make sense at all (think rings). This tracking of test status is not in the tool. And tests should gate further work based on test status. And tests, automatic or manual, have a smart and a stupid order doing them.
What would be really nice here, is to have hooks in BS like github. If new pull request is created, then there is hook that can told it to CI like https://travis-ci.org/
http://openbuildservice.org/2013/11/22/Source-Update-Via_Token/ ?
or code quality metter like https://codeclimate.com/ which in response set status for such request so you immediatelly see if request passes tests or if quality of code goes up or down ( I think it will be really useful for e.g. rpmlint warnings, now I don't see if submit request increase or decrease number of warnings ). Now it is partially done in BS itself with their own check if rpm build. And if it is generic, then we can easily add different services in future like attach to project security scanner and check if in new version is new security warning. I prefer component system before monolitic application.
Yes, my idea here is to offer also such a trigger mechanism as described in the blog URL above to handle review states in requests. So, an external tool can be used more easily without the need to store user credentials on that system. Would this be a solution? -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org