[yast-devel] Change of Jenkins jobs for automated package submissions
Hello, this morning I was pointed out that (another?) package lacks the job assuring automated package submission to CaaSP. It is just too simple to forget to set the job up when a package needs to be branched to a specific product. I briefly talked to Lukas and Ladislav about possible solution. 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 The idea is to "merge" all such jobs into one, taking care of all development branches (currently master and CASP) into a single one: yast2-autoinstallation-devel 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? We can discuss this at the end of the daily stand-up... 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
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.
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. 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.
We can discuss this at the end of the daily stand-up...
Good idea... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
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
Dne 15.2.2017 v 12:44 Jiri Srain napsal(a):
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 ;-)
If SLE12 will be developed in master then there is no change... Another possibility is to use this rule: Whenever you create the CASP branch in Git craete the respective Jenkins Job. That's really trivial: - Go to https://ci.suse.de/view/YaST/ - Press "Login" in the right top corner, use the credentials from https://wiki.microfocus.net/index.php/YaST/jenkins#SUSE_.28internal.29 - In the left menu select "New" - Enter the new job name (e.g. "yast-foo-CASP"), in the "Copy from' field select the existing master job, e.g. "yast-foo-master". - Leave the "Add to current view" option checked, press "OK" - Change "Branches to build" from "master" to "SLE-12-SP2-CASP" - "Save" and that's it! -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 15.2.2017 v 10:44 Jiri Srain napsal(a):
We can discuss this at the end of the daily stand-up...
JFYI: At that discussion we decided to create separate jobs for each branch. That means we will create the CASP jobs for all YaST packages. The initial submission still needs to be done manually, expect a failure for the first Jenkins build. But at least we will get an email from Jenkins so we should not forget about this. -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
Jiri Srain -
Ladislav Slezak