Mailinglist Archive: yast-devel (127 mails)

< Previous Next >
Re: [yast-devel] Adding snapper/libstorage to Jenkins
On Thu, 5 Nov 2015 11:51:37 +0100
Arvin Schnell <aschnell@xxxxxxxx> wrote:

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@xxxxxxxx> 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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups