[yast-devel] Adding snapper/libstorage to Jenkins
Moin, I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution: 1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support 3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel) 4. make -f Makefile.repo && rake osc:build This currently SUCCEEDS! :) Yast projects have .spec files in their /package directories, but snapper has snapper.spec.in and the .spec file is then generated on-the-fly. Although the current Jenkins solution is really ugly as it brings too many new dependencies into the infrastructure, it's a step forward (at least I hope so). So, what do you think of that? How bad is 'bad', how ugly is 'ugly' :)? PS: If you can't access some pieces of the infrastructure, then you just can't, and I'm sorry -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 3 Nov 2015 15:33:36 +0100
Lukas Ocilka
Moin,
I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution:
1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support 3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
This is for me the most ugly part. There is huge risk for us to again hit problems like: 1) package is for Leap, but versions above is for factory 2) worker do not have recent enough versions, so we do not detect problems earlier 3) we have to maintain it on server side. That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
4. make -f Makefile.repo && rake osc:build
This currently SUCCEEDS! :)
Yast projects have .spec files in their /package directories, but snapper has snapper.spec.in and the .spec file is then generated on-the-fly. Although the current Jenkins solution is really ugly as it brings too many new dependencies into the infrastructure, it's a step forward (at least I hope so). So, what do you think of that? How bad is 'bad', how ugly is 'ugly' :)?
For me nice step forward, but we really have to remove such dependencies in tarball creation process. Josef
PS: If you can't access some pieces of the infrastructure, then you just can't, and I'm sorry
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Nov 03, 2015 at 03:55:12PM +0100, Josef Reidinger wrote:
Lukas Ocilka
wrote:
I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution:
1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support 3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
This is for me the most ugly part. There is huge risk for us to again hit problems like:
2) worker do not have recent enough versions, so we do not detect problems earlier
Detecting problems as early as possible is good - not a problem.
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
Just create a VM in the cloud, start the correct image, do the
packaging and delete the VM again. Isn't that the whole idea of
the cloud?
ciao Arvin
--
Arvin Schnell,
Dne 3.11.2015 v 16:32 Arvin Schnell napsal(a):
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
Just create a VM in the cloud, start the correct image, do the packaging and delete the VM again. Isn't that the whole idea of the cloud?
Yes, you could use cloud, but it's too complicated. Running a special VM just to create a simple tarball from Git checkout sounds crazy to me... Remember what you need to do if you want to build an YaST package for SLE11 - you need installed yast2-devtools in the appropriate version + all tools used (like autoconf, automake,...) + the needed libraries. You need different set of packages for each SP release, that's too complicated even with the help of VMs. On the other hand with the new simple git tarball approach you just need git and tar basically in any version. You do not need the build dependencies. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz 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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 12:06:45AM +0100, Ladislav Slezak wrote:
Dne 3.11.2015 v 16:32 Arvin Schnell napsal(a):
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
Just create a VM in the cloud, start the correct image, do the packaging and delete the VM again. Isn't that the whole idea of the cloud?
Yes, you could use cloud, but it's too complicated. Running a special VM just to create a simple tarball from Git checkout sounds crazy to me...
You can also run unit test, code coverage and some integration tests in the VM. Apart from that the VM is not so special, just the standard SDK is needed.
Remember what you need to do if you want to build an YaST package for SLE11 - you need installed yast2-devtools in the appropriate version + all tools used (like autoconf, automake,...) + the needed libraries. You need different set of packages for each SP release, that's too complicated even with the help of VMs.
Don't think about all the different packages but about a
different distribution. Then it is not complicated at all. I
always do development for old distributions in VMs. You need them
for testing anyway.
ciao Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 10:32:23 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 12:06:45AM +0100, Ladislav Slezak wrote:
Dne 3.11.2015 v 16:32 Arvin Schnell napsal(a):
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
Just create a VM in the cloud, start the correct image, do the packaging and delete the VM again. Isn't that the whole idea of the cloud?
Yes, you could use cloud, but it's too complicated. Running a special VM just to create a simple tarball from Git checkout sounds crazy to me...
You can also run unit test, code coverage and some integration tests in the VM. Apart from that the VM is not so special, just the standard SDK is needed.
unit tests should be run in test phase of build process, so osc build should do it for you with all required libraries. Code coverage is a bit tricky, but you usually do not do it on jenkins just for code submission. For integration testing it is needed to have proper env, but it require to really maintain such VMs, which is a bit time demanding. Just consider you have security fix that goes to SLE11 SP1, SP2, SP3, SP4 and SLE12 GA, SP1....so in your way you have to start 6 VMs which have to be updated. with git tarball and osc approach, you do testing just once or twice ( 11 and 12) and rest is covered by unit tests in test phase.
Remember what you need to do if you want to build an YaST package for SLE11 - you need installed yast2-devtools in the appropriate version + all tools used (like autoconf, automake,...) + the needed libraries. You need different set of packages for each SP release, that's too complicated even with the help of VMs.
Don't think about all the different packages but about a different distribution. Then it is not complicated at all. I always do development for old distributions in VMs. You need them for testing anyway.
And you need also to maintain it and whats more, if other need to do some development, then it is a bit tricky to set it up correctly. Just stop thinking for a moment about snapper and libstorage. Imagine that we need urgent fix for yast2-ruby-bindings and you as C++ expert look at it and fix it. Is easier for you to do git clone hacking/writing unit test rake osc:build Or use proper VM, set properly cmake, install all required packages in proper versions, create a tarball ( in cmake very tricky as there is at least three different commands that can do it and result is different ), generate spec file and then copy it to osc checkout directory? I think majority of team prefer first way and are happy with way how is easy to submit now yast/libyui packages. Josef
ciao Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05.11.2015 11:03, Josef Reidinger wrote:
git clone hacking/writing unit test rake osc:build
Huh?
Do you seriously think just 'git clone' will get you anywhere?
This wouldn't even work with helloworld.cc, let alone with something
nontrivial such as libstorage, libyui, libyui-qt, libyqui-qt-pkg and
whatnot.
You need to set up a development environment. You need a working
compiler with everything and roughly a dozen -devel packages for all
kinds of libs. You need quite a number of them in the correct version.
You need a number of them from some Devel:Something repo on OBS or IBS.
And I probably forgot a number of steps in this list.
Setting up such a development environment from scratch will take a very
efficient developer with the necessary know-how about half a day. For
somebody less experienced, I'd guess it's more like half a week until
everything is working.
That scenario is just unrealistic. If we can get 'rake osc:build' on top
of everything else, that's fine with me. But this is NOT a substitute
(it doesn't even come close) to a working Autotools environment (even
CMake is inferior to that IMHO).
We cannot and we don't want to dumb down the C++ development
environments that much. That would hit us hard in our everyday work.
Kind regards
--
Stefan Hundhammer
On Thu, 5 Nov 2015 11:45:24 +0100
Stefan Hundhammer
On 05.11.2015 11:03, Josef Reidinger wrote:
git clone hacking/writing unit test rake osc:build
Huh?
Do you seriously think just 'git clone' will get you anywhere? This wouldn't even work with helloworld.cc, let alone with something nontrivial such as libstorage, libyui, libyui-qt, libyqui-qt-pkg and whatnot.
You need to set up a development environment. You need a working compiler with everything and roughly a dozen -devel packages for all kinds of libs. You need quite a number of them in the correct version. You need a number of them from some Devel:Something repo on OBS or IBS. And I probably forgot a number of steps in this list.
No, it is not true. you can simple modify C code and then run osc:build and it sets build environment for you including all required devel libraries, compilers and others. So just try it, e.g. yast2-core or yast2-ruby-bindings and you see it yourself.
Setting up such a development environment from scratch will take a very efficient developer with the necessary know-how about half a day. For somebody less experienced, I'd guess it's more like half a week until everything is working.
osc do it for you in chroot with real used dependencies.
That scenario is just unrealistic. If we can get 'rake osc:build' on top of everything else, that's fine with me. But this is NOT a substitute (it doesn't even come close) to a working Autotools environment (even CMake is inferior to that IMHO).
why not? rpm spec have to do it also.
We cannot and we don't want to dumb down the C++ development environments that much. That would hit us hard in our everyday work.
"we" mean you? or is there some group that think that for any small trivial change in any package you need halg day setup of your environment. Even for trivial typo fix? Of course if you do regularly such work, it make sense to have specialized environment for development, but please do not force everyone wanting to do any change in package to spend such time. Josef
Kind regards
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05.11.2015 12:40, Josef Reidinger wrote:
"we" mean you? or is there some group that think that for any small trivial change in any package you need halg day setup of your environment. Even for trivial typo fix? Of course if you do regularly such work, it make sense to have specialized environment for development, but please do not force everyone wanting to do any change in package to spend such time.
This is a cardinal error in this thought: Make life hard for those who
do it everyday - and try to make it easy for those who do it once in a
while.
If only such people actually existed.
CU
--
Stefan Hundhammer
On Thu, 5 Nov 2015 13:24:12 +0100
Stefan Hundhammer
On 05.11.2015 12:40, Josef Reidinger wrote:
"we" mean you? or is there some group that think that for any small trivial change in any package you need halg day setup of your environment. Even for trivial typo fix? Of course if you do regularly such work, it make sense to have specialized environment for development, but please do not force everyone wanting to do any change in package to spend such time.
This is a cardinal error in this thought: Make life hard for those who do it everyday - and try to make it easy for those who do it once in a while.
How easy tarball creation can make your life harder? What changed for you? I do not want to force anything to any developer, I just say that some of our current stuff is hard to do isolated. you can still use your VMs, I do not see how this changed. Josef
If only such people actually existed.
CU
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 5.11.2015 13:24, Stefan Hundhammer wrote:
On 05.11.2015 12:40, Josef Reidinger wrote:
"we" mean you? or is there some group that think that for any small trivial change in any package you need halg day setup of your environment. Even for trivial typo fix? Of course if you do regularly such work, it make sense to have specialized environment for development, but please do not force everyone wanting to do any change in package to spend such time.
This is a cardinal error in this thought: Make life hard for those who do it everyday - and try to make it easy for those who do it once in a while.
This is a little example of what I did to make the life hard for those who contribute to snapper daily: https://github.com/openSUSE/snapper/compare/master...kobliha:jenkins_support Is it really so? Does it make their life harder? How? This just created a package from Git, nothing more, nothing less. L. -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 5.11.2015 12:40, Josef Reidinger wrote:
We cannot and we don't want to dumb down the C++ development environments that much. That would hit us hard in our everyday work.
"we" mean you? or is there some group that think that for any small trivial change in any package you need halg day setup of your environment. Even for trivial typo fix? Of course if you do regularly such work, it make sense to have specialized environment for development, but please do not force everyone wanting to do any change in package to spend such time.
And this is what brings me back to square 1: Déjà vu If I'm not mistaken, HuHa was recently complaining about "You have to do too many things to fix a little thing in Yast". This is the same. Let's keep Jenkins Simple and Stupid: - Create *.spec and *.tar.bz2 - Call OBS to build it - Run unit tests during build Is there anything simpler than that? Anyone can still do this manually, even for different distributions. Anyone can start their VMs if they want. I'm sorry, but I'm definitely against anything (else) that we would need to keep maintaining in the future, such as connector to Cloud for running some pre-built images. What I want is to make the life easier for developers - auto-check and auto-submission to correct projects, that's it. We already have a pretty example how this could work: All Yast projects. Thanks in advance Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 11:03:24AM +0100, Josef Reidinger wrote:
On Thu, 5 Nov 2015 10:32:23 +0100 Arvin Schnell
wrote:
You can also run unit test, code coverage and some integration tests in the VM. Apart from that the VM is not so special, just the standard SDK is needed.
unit tests should be run in test phase of build process, so osc build should do it for you with all required libraries. Code coverage is a bit tricky, but you usually do not do it on jenkins just for code submission.
I have heard that we want to move code coverage from Travis to Jenkins.
For integration testing it is needed to have proper env, but it require to really maintain such VMs, which is a bit time demanding.
Maintain such VMs? Those are standard images just started. If the VM has a unused disk some integration tests for libstorage and snapper would already be possible.
Just consider you have security fix that goes to SLE11 SP1, SP2, SP3, SP4 and SLE12 GA, SP1....so in your way you have to start 6 VMs which have to be updated. with git tarball and osc approach, you do testing just once or twice ( 11 and 12) and rest is covered by unit tests in test phase.
Jenkins starts the VMs, not me. And they don't have to be updated. Jenkins just starts the latest image for each distribution. Unit tests are run in any case, not just your way.
Remember what you need to do if you want to build an YaST package for SLE11 - you need installed yast2-devtools in the appropriate version + all tools used (like autoconf, automake,...) + the needed libraries. You need different set of packages for each SP release, that's too complicated even with the help of VMs.
Don't think about all the different packages but about a different distribution. Then it is not complicated at all. I always do development for old distributions in VMs. You need them for testing anyway.
And you need also to maintain it and whats more, if other need to do some development, then it is a bit tricky to set it up correctly. Just stop thinking for a moment about snapper and libstorage. Imagine that we need urgent fix for yast2-ruby-bindings and you as C++ expert look at it and fix it. Is easier for you to do
git clone hacking/writing unit test
And here you want a complete system where you can compile the sources directly from your editor. So you need a VM/system.
rake osc:build
Far too slow to find mistakes in the sources. Also your IDE will not simply jump to the file with the error. Turn around time increases from few seconds to several minutes killing productivity.
Or use proper VM, set properly cmake, install all required packages in proper versions, create a tarball ( in cmake very tricky as there is at least three different commands that can do it and result is different ), generate spec file and then copy it to osc checkout directory?
You just gave some reasons to drop cmake.
Apart from that those tasks have to be done only once but the
development itself is much faster that your repeating 'rake
osc:build' version.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 11:51:37 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 11:03:24AM +0100, Josef Reidinger wrote:
On Thu, 5 Nov 2015 10:32:23 +0100 Arvin Schnell
wrote: You can also run unit test, code coverage and some integration tests in the VM. Apart from that the VM is not so special, just the standard SDK is needed.
unit tests should be run in test phase of build process, so osc build should do it for you with all required libraries. Code coverage is a bit tricky, but you usually do not do it on jenkins just for code submission.
I have heard that we want to move code coverage from Travis to Jenkins.
yes, thanks plan, but as I said it is not critical for code submission.
For integration testing it is needed to have proper env, but it require to really maintain such VMs, which is a bit time demanding.
Maintain such VMs? Those are standard images just started. If the VM has a unused disk some integration tests for libstorage and snapper would already be possible.
keeping it up to date, world around changed, so also VM need some love. I already have over 20 vms for various env and for older one, there is always problems when started that something outside changed ( e.g. YaST:Devel no longer support the old distribution, maintenance updates released, etc. )
Just consider you have security fix that goes to SLE11 SP1, SP2, SP3, SP4 and SLE12 GA, SP1....so in your way you have to start 6 VMs which have to be updated. with git tarball and osc approach, you do testing just once or twice ( 11 and 12) and rest is covered by unit tests in test phase.
Jenkins starts the VMs, not me. And they don't have to be updated. Jenkins just starts the latest image for each distribution.
jenkins now use osc which use chroot, so more docker like solution. Why is using VMs better then using osc chroot? And it is not image for each distribution, it is image for each distribution and each package, as you env is different for each package ( devel libraries for yast2-core is different then for snapper ). And also do not forget about interdependencies. New snapper maybe need new libbtrfs library, so it also have to be updated.
Unit tests are run in any case, not just your way.
it is not my way, it is just one way during rpm build. So I do not see sense to run it more then once during one submission.
Remember what you need to do if you want to build an YaST package for SLE11 - you need installed yast2-devtools in the appropriate version + all tools used (like autoconf, automake,...) + the needed libraries. You need different set of packages for each SP release, that's too complicated even with the help of VMs.
Don't think about all the different packages but about a different distribution. Then it is not complicated at all. I always do development for old distributions in VMs. You need them for testing anyway.
And you need also to maintain it and whats more, if other need to do some development, then it is a bit tricky to set it up correctly. Just stop thinking for a moment about snapper and libstorage. Imagine that we need urgent fix for yast2-ruby-bindings and you as C++ expert look at it and fix it. Is easier for you to do
git clone hacking/writing unit test
And here you want a complete system where you can compile the sources directly from your editor. So you need a VM/system.
No, for compilation you use osc, which already have information what is dependencies and whats more, it is done in chroot, so your working environment is not broken by installing any library. For me osc chroot is like docker, so more lightweigth then VM and also without any maintenance.
rake osc:build
Far too slow to find mistakes in the sources. Also your IDE will not simply jump to the file with the error. Turn around time increases from few seconds to several minutes killing productivity.
As I said, if you regularly work with project it make sense to have own specialized env, e.g. in VM, but current way force everyone to use it, even if you want to fix typo or trivial case. Where few minutes for compilation is balanced by not seting up whole VMs with development environment. Try to be friendly to non-regular contributors and new comers. I do not say that using VM is wrong, I just say that forcing it to use by everyone is wrong.
Or use proper VM, set properly cmake, install all required packages in proper versions, create a tarball ( in cmake very tricky as there is at least three different commands that can do it and result is different ), generate spec file and then copy it to osc checkout directory?
You just gave some reasons to drop cmake.
And also autotools, which from my POV is same beast written in obscure language (M4), need configuration ( what is enabled, what not ), adds own specific make tasks, etc.
Apart from that those tasks have to be done only once but the development itself is much faster that your repeating 'rake osc:build' version.
See above reasons for regular contributors versus newcomers or non-regular contributors. Josef
Regards, Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 12:51:43PM +0100, Josef Reidinger wrote:
Maintain such VMs? Those are standard images just started. If the VM has a unused disk some integration tests for libstorage and snapper would already be possible.
keeping it up to date, world around changed, so also VM need some love. I already have over 20 vms for various env and for older one, there is always problems when started that something outside changed ( e.g. YaST:Devel no longer support the old distribution, maintenance updates released, etc. )
No, you are not taking about the cloud but just a hand full of machines. I propose to just take the latest image from the buildservice, create a VM and start it. Afterwards you delete the VM again. I have heard Amazon makes good money with that concept.
jenkins now use osc which use chroot, so more docker like solution. Why is using VMs better then using osc chroot?
Well, if Jenkins already uses chroot we can create the package there. That would not require changes to the source code. Or am I missing something?
And it is not image for each distribution, it is image for each distribution and each package, as you env is different for each package ( devel libraries for yast2-core is different then for snapper ).
That is entirely exaggerated: On my machine I can work on libstorage, snapper and yast2-core without having to change the set of installed packages. Maybe that's different in the Ruby world but for C/C++ some extra libraries in general do not hurt.
And also do not forget about interdependencies. New snapper maybe need new libbtrfs library, so it also have to be updated.
By taking the latest image from the buildservice the library is up to date. If not the build will also fail and submitting is not an option.
And here you want a complete system where you can compile the sources directly from your editor. So you need a VM/system.
No, ...
I do want that and I'm not alone with that view.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 14:14:33 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 12:51:43PM +0100, Josef Reidinger wrote:
Maintain such VMs? Those are standard images just started. If the VM has a unused disk some integration tests for libstorage and snapper would already be possible.
keeping it up to date, world around changed, so also VM need some love. I already have over 20 vms for various env and for older one, there is always problems when started that something outside changed ( e.g. YaST:Devel no longer support the old distribution, maintenance updates released, etc. )
No, you are not taking about the cloud but just a hand full of machines. I propose to just take the latest image from the buildservice, create a VM and start it. Afterwards you delete the VM again. I have heard Amazon makes good money with that concept.
you need to maintain such images, or you think someone magically create for you latest snapper devel image? Or you have to always install it from beginning to get all required packages and dependencies...but wait, maybe osc already do it.
jenkins now use osc which use chroot, so more docker like solution. Why is using VMs better then using osc chroot?
Well, if Jenkins already uses chroot we can create the package there. That would not require changes to the source code. Or am I missing something?
No, as osc need 1) spec file ( now you need whole autotools monster with its dependencies to generate it ) 2) tarball ( same problem with autotools beast ) That is reason why yast now have simple command to create tarball, spec files are not generated and rest is done inside osc that ensure proper environment according to requirements from spec file.
And it is not image for each distribution, it is image for each distribution and each package, as you env is different for each package ( devel libraries for yast2-core is different then for snapper ).
That is entirely exaggerated: On my machine I can work on libstorage, snapper and yast2-core without having to change the set of installed packages. Maybe that's different in the Ruby world but for C/C++ some extra libraries in general do not hurt.
so you propose to create such heavy weight beast image that contain all development libraries in our cloud setup? And ensure everything is up to date. And to be honest it is not some, it is a lot of libraries, its devel packages and generators ( like bison or flex ). So you create for all distribution such beast with tons of extra libraries and then using it? And do you expect that newcomers do it same way? I think maybe some other people that touch yast and snapper or libstorage can compare how hard/easy is to contribute and use such infrastructure, how well it is documented and so on.
And also do not forget about interdependencies. New snapper maybe need new libbtrfs library, so it also have to be updated.
By taking the latest image from the buildservice the library is up to date. If not the build will also fail and submitting is not an option.
So you expect buildservice create such beast image that contain all devel libraries? Do you ask build service team how they like it? Because every small change trigger rebuild of that beast having tenths of GB
And here you want a complete system where you can compile the sources directly from your editor. So you need a VM/system.
No, ...
I do want that and I'm not alone with that view.
As I said, having simple way to have spec file and tarball do not break your workflow with compilation in your VMs. I just do not like that your view is now only way how to do it (r). Josef
Regards, Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 02:28:24PM +0100, Josef Reidinger wrote:
you need to maintain such images, or you think someone magically create
so you propose to create such heavy weight beast image that contain all
So you create for all distribution such beast with tons of extra
Sorry, the language I read here is not the kind I would like to
see in a professional discussion.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 14:35:32 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 02:28:24PM +0100, Josef Reidinger wrote:
you need to maintain such images, or you think someone magically create
so you propose to create such heavy weight beast image that contain all
So you create for all distribution such beast with tons of extra
Sorry, the language I read here is not the kind I would like to see in a professional discussion.
Regards, Arvin
OK, if you prefer cow and sheep language used in cloud for machine clasiffication I am fine with it, but it is a lot off topic. I think nothing can convince you that your way is only right one and others do it wrong and it is waste of time to make other ways easier. So I stop wasting my time. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 02:28:24PM +0100, Josef Reidinger wrote:
On Thu, 5 Nov 2015 14:14:33 +0100 Arvin Schnell
wrote: On Thu, Nov 05, 2015 at 12:51:43PM +0100, Josef Reidinger wrote:
Maintain such VMs? Those are standard images just started. If the VM has a unused disk some integration tests for libstorage and snapper would already be possible.
keeping it up to date, world around changed, so also VM need some love. I already have over 20 vms for various env and for older one, there is always problems when started that something outside changed ( e.g. YaST:Devel no longer support the old distribution, maintenance updates released, etc. )
No, you are not taking about the cloud but just a hand full of machines. I propose to just take the latest image from the buildservice, create a VM and start it. Afterwards you delete the VM again. I have heard Amazon makes good money with that concept.
you need to maintain such images, or you think someone magically create for you latest snapper devel image?
Well, yes: https://build.opensuse.org/project/show/home:aschnell:build-appliance
That is entirely exaggerated: On my machine I can work on libstorage, snapper and yast2-core without having to change the set of installed packages. Maybe that's different in the Ruby world but for C/C++ some extra libraries in general do not hurt.
so you propose to create such heavy weight beast image that contain all development libraries in our cloud setup? And ensure everything is up to date. And to be honest it is not some, it is a lot of libraries, its devel packages and generators ( like bison or flex ).
So you create for all distribution such beast with tons of extra libraries and then using it?
The appliance above, which has everything to compile, unit-test, and package snapper, libstorage and libstorage-bgl-eval, is not hugh, below half of a GB.
And do you expect that newcomers do it same way?
No, the appliance is for Jenkins, not developers.
Regards,
Arvin
--
Arvin Schnell,
On 5.11.2015 14:28, Josef Reidinger wrote:
That is entirely exaggerated: On my machine I can work on libstorage, snapper and yast2-core without having to change the set of installed packages. Maybe that's different in the Ruby world but for C/C++ some extra libraries in general do not hurt.
so you propose to create such heavy weight beast image that contain all development libraries in our cloud setup? And ensure everything is up to date. And to be honest it is not some, it is a lot of libraries, its devel packages and generators ( like bison or flex ).
So you create for all distribution such beast with tons of extra libraries and then using it? And do you expect that newcomers do it same way? I think maybe some other people that touch yast and snapper or libstorage can compare how hard/easy is to contribute and use such infrastructure, how well it is documented and so on.
Let's put it this way: Let developers do what they want - I do not care how and where someone develops code if it's good, understandable, well-covered by unit tests and well-documented. But what I do care is this: when we have a continuous automation for validation (build and check), then I want it to be simple and unified. I do not want special hacky per-repository Sherl scripts, cloud images, or anything like that. I want to use tools that exist for the purpose they can do best. As an example: build service builds packages, we have to use it anyway (OBS/IBS) and thus I want build service for that task. Thank you Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 3.11.2015 16:32, Arvin Schnell wrote:
2) worker do not have recent enough versions, so we do not detect problems earlier
Detecting problems as early as possible is good - not a problem.
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
Just create a VM in the cloud, start the correct image, do the packaging and delete the VM again. Isn't that the whole idea of the cloud?
Except the fact, that this is definitely - Beyond of the scope of putting snapper/libstorage to Jenkins - Yet another type of build process that we would need to maintain - Far from trivial or simple enough This is also the reason why I simply decided to use Yast build tools: We already maintain them anyway, they work even for non-Ruby projects (core), we have the infrastructure in place. Yes, I agree, that adding Ruby/Rake into snapper just because of these things is not a good reason, we just need to make libyui-rake a bit more generic (+ rename), prepare snapper for that tool and then convert. My little project was more about trying and failing in a way that shows what needs to be done. It's some kind of a Proof of Concept. Now I'm putting the task back to Sprint Backlog. HTH and Thanks for your opinions Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 10:03:55AM +0100, Lukas Ocilka wrote:
This is also the reason why I simply decided to use Yast build tools: We already maintain them anyway, they work even for non-Ruby projects (core), we have the infrastructure in place.
Yes, I agree, that adding Ruby/Rake into snapper just because of these things is not a good reason, we just need to make libyui-rake a bit more generic (+ rename), prepare snapper for that tool and then convert.
Please remember that snapper is used by several other
distributions and compiled by individual people from
source. Forcing them to use some special tools is not what I
recommend.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 10:40:29 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 10:03:55AM +0100, Lukas Ocilka wrote:
This is also the reason why I simply decided to use Yast build tools: We already maintain them anyway, they work even for non-Ruby projects (core), we have the infrastructure in place.
Yes, I agree, that adding Ruby/Rake into snapper just because of these things is not a good reason, we just need to make libyui-rake a bit more generic (+ rename), prepare snapper for that tool and then convert.
Please remember that snapper is used by several other distributions and compiled by individual people from source. Forcing them to use some special tools is not what I recommend.
Why not use osc for building it for several distributions? rake is used mainly for tarball creation and running osc, so just document that for manual creation of tarball you should run package output of `git ls-files . | grep -v \\.gitignore` You speak about special tools, but other distros also use approach of metadata + tarball, so you think they are happy that they need to create simple f***ing tarball bunch of development libraries? If you distribute for them tarball, they do not need using rake at all. Also it can be configured to not add Rakefile at all to archive, if you distribute it. And last but not least, gems and ruby is available on all distributions, can be simple installed and is well documented, so I do not see it as special obstacle. BTW there are projects that use cmake, scons, qmake and others, and to be honest I found ruby better scripting language then m4, cmake or qmake language. Josef
Regards, Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05.11.2015 11:11, Josef Reidinger wrote:
Why not use osc for building it for several distributions?
That's fine for a great number of users, but some of them will always want to build their own - because of the Open Source spirit, because they think it's educational for them, or because they feel safer that way (considerably less risk for getting malware through the back door).
rake is used mainly for tarball creation and running osc, so just document that for manual creation of tarball you should run package output of `git ls-files . | grep -v \\.gitignore`
No, not document some arcane command, simply provide the command that does it. And IMHO we can only realistically provide it if that's the command we use on an everyday basis; otherwise bit rot will set in fast.
You speak about special tools, but other distros also use approach of metadata + tarball, so you think they are happy that they need to create simple f***ing tarball bunch of development libraries?
That's the same for all non-trivial software: They all need some kinds of libraries the host system has to provide. But they might even want to provide their own version (or simply an older, but maybe more stable version) of any of them. This is their choice, and again, it's the spirit of Open Source to let them make that choice. ...
And last but not least, gems and ruby is available on all distributions, can be simple installed and is well documented, so I do not see it as special obstacle.
Unless some people choose not to use that technology at all (for ideological reasons). For example, I always gave all Mono based software a wide berth. I simply didn't want it on my system. There is a psychological threshold when people don't use your software. If it delivers great value, if it's useful to the user, if it's a joy to use, people want it. If it's a PITA to build, they won't build it, even if it's the coolest and most useful software in the world. And if that affects people who want to build their own in every case (e.g., Gentoo fans), you'll loose those potential users, thus shrinking your user base for no good reason.
BTW there are projects that use cmake, scons, qmake and others, and to be honest I found ruby better scripting language then m4, cmake or qmake language.
None of m4, cmake or qmake are general purpose scripting languages. m4
is a macro processor (that was pressed into service for the Autotools),
cmake and qmake are purpose-built make tools.
Rake is a mixture. It's still kind of Ruby, but OTHO it's some kind of
build tool. It's hard to compare. Rake certainly does have its place for
Ruby development, but IMHO it's a misuse to use it for everything just
because it's there.
You know, if your only tool is a hammer, every problem looks like a
nail. Let's not go there. ;-)
Kind regards
--
Stefan Hundhammer
On Thu, 5 Nov 2015 11:57:53 +0100
Stefan Hundhammer
On 05.11.2015 11:11, Josef Reidinger wrote:
Why not use osc for building it for several distributions?
That's fine for a great number of users, but some of them will always want to build their own - because of the Open Source spirit, because they think it's educational for them, or because they feel safer that way (considerably less risk for getting malware through the back door).
rake is used mainly for tarball creation and running osc, so just document that for manual creation of tarball you should run package output of `git ls-files . | grep -v \\.gitignore`
No, not document some arcane command, simply provide the command that does it. And IMHO we can only realistically provide it if that's the command we use on an everyday basis; otherwise bit rot will set in fast.
My problem is that current command require whole complex development environment. Just try to visit some of your collegues that do e.g. packaging of perl scripts and let them try to create package for snapper. I think you will see that installing many various packages is not so funny just to create one tarball.
You speak about special tools, but other distros also use approach of metadata + tarball, so you think they are happy that they need to create simple f***ing tarball bunch of development libraries?
That's the same for all non-trivial software: They all need some kinds of libraries the host system has to provide. But they might even want to provide their own version (or simply an older, but maybe more stable version) of any of them.
Sorry, but which non-trivial software require to create archive many kind of libraries in host system? We are talking about creating archive, not about compilation, verification, validation or others.
This is their choice, and again, it's the spirit of Open Source to let them make that choice.
Yeah, but choices have consequences. If you set up pub and say that taking food away you have to bring your own box, duck tape, salt, pepper and spoon. Try estimate how many people take away food. And for me it is same for snapper here. You just want to create tarball on your own.
...
And last but not least, gems and ruby is available on all distributions, can be simple installed and is well documented, so I do not see it as special obstacle.
Unless some people choose not to use that technology at all (for ideological reasons). For example, I always gave all Mono based software a wide berth. I simply didn't want it on my system.
There is a psychological threshold when people don't use your software. If it delivers great value, if it's useful to the user, if it's a joy to use, people want it. If it's a PITA to build, they won't build it, even if it's the coolest and most useful software in the world. And if that affects people who want to build their own in every case (e.g., Gentoo fans), you'll loose those potential users, thus shrinking your user base for no good reason.
I can use same reasons for not forcing to use tons of software and libraries just to create tarball that can be used to build package on other distributions.
BTW there are projects that use cmake, scons, qmake and others, and to be honest I found ruby better scripting language then m4, cmake or qmake language.
None of m4, cmake or qmake are general purpose scripting languages. m4 is a macro processor (that was pressed into service for the Autotools), cmake and qmake are purpose-built make tools.
Rake is a mixture. It's still kind of Ruby, but OTHO it's some kind of build tool. It's hard to compare. Rake certainly does have its place for Ruby development, but IMHO it's a misuse to use it for everything just because it's there.
You know, if your only tool is a hammer, every problem looks like a nail. Let's not go there. ;-)
I am fine if someone create similar tool for submission in plain shell or anything else, but currently there is not such tool, so we reuse existing one. For me big advantage of rake/ruby is readability and easy code sharing, but in general tasks done by it, can be done by simple shell script as it is just invocation of shell commands like git, osc and tar ) compare https://github.com/libyui/libyui-qt-pkg/blob/master/Rakefile ( one liner saying nothing unstandard ) with https://github.com/openSUSE/snapper/blob/master/configure.ac or https://github.com/openSUSE/snapper/blob/master/Makefile.repo ( which is kind of top level one, but not completelly ) Josef
Kind regards
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 01:03:00PM +0100, Josef Reidinger wrote:
My problem is that current command require whole complex development environment. Just try to visit some of your collegues that do e.g. packaging of perl scripts and let them try to create package for snapper. I think you will see that installing many various packages is not so funny just to create one tarball.
That is not the feedback I get. When I compare the contributions
to e.g. snapper and yast2-storage we should change yast2-storage
but not snapper.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 13:57:32 +0100
Arvin Schnell
On Thu, Nov 05, 2015 at 01:03:00PM +0100, Josef Reidinger wrote:
My problem is that current command require whole complex development environment. Just try to visit some of your collegues that do e.g. packaging of perl scripts and let them try to create package for snapper. I think you will see that installing many various packages is not so funny just to create one tarball.
That is not the feedback I get. When I compare the contributions to e.g. snapper and yast2-storage we should change yast2-storage but not snapper.
Regards, Arvin
Well, as one time contributor to snapper, you can count this as feedback from me. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 02:00:14PM +0100, Josef Reidinger wrote:
On Thu, 5 Nov 2015 13:57:32 +0100 Arvin Schnell
wrote: On Thu, Nov 05, 2015 at 01:03:00PM +0100, Josef Reidinger wrote:
My problem is that current command require whole complex development environment. Just try to visit some of your collegues that do e.g. packaging of perl scripts and let them try to create package for snapper. I think you will see that installing many various packages is not so funny just to create one tarball.
That is not the feedback I get. When I compare the contributions to e.g. snapper and yast2-storage we should change yast2-storage but not snapper.
Regards, Arvin
Well, as one time contributor to snapper, you can count this as feedback from me.
Thanks for the numbers: You have committed more often to snapper
than yast2-storage (13 vs. 12). So it is apparently easier with
snapper ;)
Regards,
Arvin
--
Arvin Schnell,
On 5.11.2015 13:57, Arvin Schnell wrote:
On Thu, Nov 05, 2015 at 01:03:00PM +0100, Josef Reidinger wrote:
My problem is that current command require whole complex development environment. Just try to visit some of your collegues that do e.g. packaging of perl scripts and let them try to create package for snapper. I think you will see that installing many various packages is not so funny just to create one tarball.
That is not the feedback I get. When I compare the contributions to e.g. snapper and yast2-storage we should change yast2-storage but not snapper.
Red herring. Snapper is a fancy tool built on top of btrfs (*) for making FS snapshots and playing with them, while Yast is and always was a SUSE-specific tool for installation and configuration. If you want to compare apples and apples, compare Yast before switching to Ruby and Rake and before that. Lukas * hold your stones, no need to throw them now :) -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 3.11.2015 15:55, Josef Reidinger wrote:
3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
This is for me the most ugly part. There is huge risk for us to again hit problems like: 1) package is for Leap, but versions above is for factory 2) worker do not have recent enough versions, so we do not detect problems earlier 3) we have to maintain it on server side.
As said, this was just the first step - to have something working now, to show what needs fixing/enhancing.
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
4. make -f Makefile.repo && rake osc:build
This currently SUCCEEDS! :) For me nice step forward, but we really have to remove such dependencies in tarball creation process.
Yes, I agree, but I haven't found any simpler way to generate the .spec file from .spec.in We've got rid of spec.in in all Yast repos (also) for this reason, but snapper/libstorage doesn't support it. Anyway, `make -f Makefile.repo` is in the README. `osc:build` is then used as the simplest way to create package and build it. HTH Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, Nov 05, 2015 at 09:50:29AM +0100, Lukas Ocilka wrote:
Yes, I agree, but I haven't found any simpler way to generate the .spec file from .spec.in
We've got rid of spec.in in all Yast repos (also) for this reason, but snapper/libstorage doesn't support it.
Yes, and that limitation of the new packaging process was known
and discussed at the workshop two or three years ago.
Regards,
Arvin
--
Arvin Schnell,
On Thu, 5 Nov 2015 09:50:29 +0100
Lukas Ocilka
On 3.11.2015 15:55, Josef Reidinger wrote:
3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
This is for me the most ugly part. There is huge risk for us to again hit problems like: 1) package is for Leap, but versions above is for factory 2) worker do not have recent enough versions, so we do not detect problems earlier 3) we have to maintain it on server side.
As said, this was just the first step - to have something working now, to show what needs fixing/enhancing.
That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
4. make -f Makefile.repo && rake osc:build
This currently SUCCEEDS! :) For me nice step forward, but we really have to remove such dependencies in tarball creation process.
Yes, I agree, but I haven't found any simpler way to generate the .spec file from .spec.in
We've got rid of spec.in in all Yast repos (also) for this reason, but snapper/libstorage doesn't support it.
it can be replaced by trivial bash script that do replacement. I think all autotools machinery is not needed to do trivial version ( library version ) replacement.
Anyway, `make -f Makefile.repo` is in the README. `osc:build` is then used as the simplest way to create package and build it.
yeah, README document current state, but it is not set in stone. We can make it easier for newcommers and even for oldies. Josef
HTH Lukas
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05.11.2015 11:15, Josef Reidinger wrote:
We've got rid of spec.in in all Yast repos (also) for this reason, but
snapper/libstorage doesn't support it. it can be replaced by trivial bash script that do replacement.
That's what the Autotools actually do. They are shortcuts to generate
things you could write yourself, and that people actually had
traditionally written themselves, before they got so complicated that it
got out of hand. Just look at those generated 'configure' script or
Makefiles. They all started out easy back then. ;-)
Kind regards
--
Stefan Hundhammer
On Thu, 5 Nov 2015 12:01:09 +0100
Stefan Hundhammer
On 05.11.2015 11:15, Josef Reidinger wrote:
We've got rid of spec.in in all Yast repos (also) for this reason, but
snapper/libstorage doesn't support it. it can be replaced by trivial bash script that do replacement.
That's what the Autotools actually do. They are shortcuts to generate things you could write yourself, and that people actually had traditionally written themselves, before they got so complicated that it got out of hand. Just look at those generated 'configure' script or Makefiles. They all started out easy back then. ;-)
Kind regards
My problem is that it is not unix way "do one thing and do it good". only thing that jenkins need is generate tarball, have spec and have changes -> then call osc build. For this kind of stuff autotools require you to have compiler, all devel libraries, complete autotools, all generators and probably also all software needed for testing. So autotools instead of providing set of commands that are independent release huge beast from hell pit and require dozens of villagers just to do trivial task. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 5.11.2015 11:15, Josef Reidinger wrote:
4. make -f Makefile.repo && rake osc:build
This currently SUCCEEDS! :) For me nice step forward, but we really have to remove such dependencies in tarball creation process.
Yes, I agree, but I haven't found any simpler way to generate the .spec file from .spec.in
We've got rid of spec.in in all Yast repos (also) for this reason, but snapper/libstorage doesn't support it.
it can be replaced by trivial bash script that do replacement. I think all autotools machinery is not needed to do trivial version ( library version ) replacement.
I definitely agree.
Anyway, `make -f Makefile.repo` is in the README. `osc:build` is then used as the simplest way to create package and build it.
yeah, README document current state, but it is not set in stone. We can make it easier for newcommers and even for oldies.
README is usually the place where newcomers start. Let's plan this again for new sprint and take old gangsters, different distributions and wild newcomers into account. I believe we need a simple working solution reusing what we already have somewhere already (e.g. OBS), instead of new infrastructure that need maintenance. I also believe that we should unify that with libyui/linuxrc?/and other C/C++ friends. No need to create YET another *-devel-build-tool for snapper and YET another for libstorage. Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Nov 03, 2015 at 03:33:36PM +0100, Lukas Ocilka wrote:
I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution:
1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support
Using two make tools in one project looks strange to me and might confuse users. Since snapper is a C++ project tools common for that language should be used.
3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
libbtrfs-devel should also be installed. Can't this information be extracted from the spec file?
4. make -f Makefile.repo && rake osc:build
The spec file we use for SUSE has a different configure command,
e.g. disabling ext4 support. The CI should use the same configure
options - or even try several different.
ciao Arvin
--
Arvin Schnell,
On 3.11.2015 16:25, Arvin Schnell wrote:
On Tue, Nov 03, 2015 at 03:33:36PM +0100, Lukas Ocilka wrote:
I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution:
1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support
Using two make tools in one project looks strange to me and might confuse users. Since snapper is a C++ project tools common for that language should be used.
Yes, there should be ideally ONE too for all C++ projects owned by Yast team. Currently libyui tools could not be used without modifications ("not mentioning" the fact, that we need to rename them). BTW, `rake` is also used for yast2-core - not a Ruby project.
3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
libbtrfs-devel should also be installed. Can't this information be extracted from the spec file?
It was not needed for creating the spec file, the rest is then done by osc:build.
4. make -f Makefile.repo && rake osc:build
The spec file we use for SUSE has a different configure command, e.g. disabling ext4 support. The CI should use the same configure options - or even try several different.
OK, thanks, but then it needs to be in the project README file. There's no way to find this out, I'm afraid, the info is hidden. Trying several different ones might be also possible, but I'd like to avoid from false-positive failures. Thx Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 05.11.2015 09:56, Lukas Ocilka wrote:
Yes, there should be ideally ONE too for all C++ projects owned by Yast team.
You mean, like back in the Good Old Days [tm] when they all used the
Autotools, before somebody came up with the bright idea to introduce
'CMake'? ;-)
SCNR ;-)
Kind regards
--
Stefan Hundhammer
participants (5)
-
Arvin Schnell
-
Josef Reidinger
-
Ladislav Slezak
-
Lukas Ocilka
-
Stefan Hundhammer