On Thu, 12 Sep 2013 10:36:42 +0200 Ladislav Slezak <[email protected]> wrote:
> 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: > [email protected] 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: [email protected] To contact the owner, e-mail: [email protected]
