On 09/11/2013 02:58 PM, Josef Reidinger wrote:
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.
It's too fragile and due to its implementation it gets obsolete pretty quickly as the list of installed packages and their versions in the check/build environment are static. The current solution also doesn't care about BuildRequires.
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.
All maintained branches would make sense. That's the only way how we can make sure nothing breaks by our change somewhere. Additionally, once a week (for instance), all the checks could be rerun even if no Yast packages were changed - it's because of the possible environment changes.
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?
Yast:Head is nice, Factory was a bit problematic as Coolo was against that - there were too many changes in Yast and Factory was rebuilding over and over. On the other hand - how to to submit to factory then? Who and when?
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?
If scripts etc. were somewhere at GitHub, it would be easier. If I could checkout these scripts and run them locally, I can cooperate on the solution (in fact, I sometimes do anyway).
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?)?
+1 from me Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org