On 15.2.2017 11:13, Ladislav Slezak wrote:
Dne 15.2.2017 v 10:44 Jiri Srain napsal(a):
Currently, we only have Jenkins jobs for branches which match products in development (not maintenance), therefore we have for instance:
yast-autoinstallation-CASP yast-autoinstallation-master
That mean in theory we would need to double the number of Jenkins jobs, in reality it won't be that bad as we need to touch much less packages for CASP.
Right. On the other hand, now it is "only" about CASP, later it may be about SLE12 vs. SLE13 (insert your favorite service pack number here ;-)
The idea is to "merge" all such jobs into one, taking care of all development branches (currently master and CASP) into a single one:
Just some details: the job defines which branches should be checked, for *-master jobs it's "master" for *-CASP jobs it's "SLE-12-SP2-CASP".
However you can list several branches in one job. So we could check for both "master" and "SLE-12-SP2-CASP" in a single job.
This would be done for all YaST packages, no matter whether it is branched for CaaSP or not (or for other products in the future). Such change would be a one-time operation via a script when we create new branch for the first package (or when product is finished); then when more packages get branched, no additional operation would be needed on top of creating the branch in Git. When the branch does not exist in Git, Jenkins would just ignore it.
This way, we would easily prevent omissions to create Jenkins job.
Does such change make sense?
Yes, it makes sense. If we need to handle more products in the future we would just need to add a new branch to the list. This would keep the total number of jobs low.
Exactly. And we should be fair to ourseves: We will need to.
But there is a small drawback. With merging the branches you will not know to which branch the job status belongs to. If the build fails you will need to check the log to see for which branch it was.
And if the job is green it does not mean it's green for all branches, that just means the latest build succeeded but for any of specified branches.
I see. Another option would probably be to create the CASP workers not only for packages which already have the CAPS branch, but to all of them (to avoid omissions later), hoping that this could be scripted. As long as the worker would not do any real work except polling the repo, would there be any drawbacks beyond seeing larger number of workers?
We can discuss this at the end of the daily stand-up...
Good idea...
Let's plan it tomorrow after standup. I will try to get some time (as I have other meeting right at 11:30 :-/ ). Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org