On Thu, Nov 05, 2015 at 11:03:24AM +0100, Josef Reidinger wrote:
On Thu, 5 Nov 2015 10:32:23 +0100 Arvin Schnell <aschnell@suse.com> 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, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org