Mailinglist Archive: yast-devel (87 mails)

< Previous Next >
Re: [yast-devel] Change of Jenkins jobs for automated package submissions

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:


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 Srain
Project Manager
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxxx
Krizikova 148/34 tel: +420 284 084 659
186 00 Praha 8 fax: +420 284 084 001
Czech Republic
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups