On Thu, 12 Sep 2013 10:36:42 +0200
Ladislav Slezak
Dne 11.9.2013 14:58, Josef Reidinger napsal(a):
Hi developers, we agreed that current CI in jenkins have some problems and I would like to face it. But at first I would like to hear your opinions on current setup, what is weak points and what is nice features we like.
Few questions I have in my mind:
testing: current it test only changes in master branch. How important for you if we automatic test also pull requests and maintenance branches? Related question is how important for us is to have generated <package>.spec file as it quite block more generic solutions.
As Lukas already mentioned all maintained branches should have CI support.
But my requirement would be to allow easily adding support for basically any branch. That would be nice for developing some big features in a topic branches. Now you do not know the current status and you realize just after merging to master that some tests are broken. That's little bit late.
Also integration with pull requests can be nice as we see imediatelly if it pass tests like travis have it.
autosubmit: Are you satisfied with current autosubmit to Yast:Head? And what about automatic submit to factory? What is criteria to submit to Yast:Head and to factory? Do you want it automatic or some someautomatic or manual step is better from your POV?
Autosubmit to YaST:Head is a nice feature, it basically means that I can just click "merge" button in a pull request at GitHub and that's it, I do not need to take care of OBS.
So YaST:Head really means "head", there are no missing commits. And there are also checks in Factory which scans for unsubmitted changes in devel projects so also Factory can find possible missing updates.
involvement: Do you want actively help with CI? ( current status is that usually I fix it myself when I see fail ) Do you have own idea what can be automatic or what can help with removing common task?
I would help, but currently there is no documentation where/what can be changed or how does it work actually. For me it looks like a black box which I do not want to touch at all to not break something...
AFAIK there is also no clear ownership, i.e. who is supposed to install updates, missing packages, who fixes the scripts etc... This also needs to be clarified.
Ideally the code should be at GitHub so we could easily know who/what/why was changed. And also code review would help to make it maintainable.
I agreed, it would be nice.
openess: Problem of current status is that yast CI lives in suse network ( benefit is that we have direct access to our test machines and can easy modify it ). What about using http://ci.opensuse.org/ instance? where then must live workers? I see that cloud guys use it, so maybe we can discuss it with them (mvidner do you have closer information?)?
What would be the benefits? What would be the drawbacks?
It also depends how big the ci.opensuse.org infrastructure is. Do they have enough resources for Yast CI? (Keep in mind that in the future we might check more branches, use more runners for parallel runs... etc. so we might need more power than right now so the possibility to extend the infrastructure is also important IMHO.)
It should run in virtual machine like we already do for river. In such case it scale really nice and even hundreds of project is fine when it just login to target node and run there bunch of commands. Josef
--
Best Regards
Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org