On 07/22/2014 05:22 PM, Luis Pabón wrote:
Hi Lala,
No problem at all, I just want to make sure that developers
understand the importance of the tool. On the topic of RPMs, they
have a really cool section called "%check", which is currently being
used to run the unit tests after the glusterfs RPM is created.
Normally developers test only on certain systems and certain
architectures, but by having the "%check" section, we can guarantee a
level of quality when an RPM is created on an architecture or
operating system version which is not normally used for development.
This actually worked really well for cmockery2 when the RPM was first
introduced to Fedora. The %check section ran the unit tests on two
architectures that I do not have, and both of them found issues on
ARM32 and s390 architectures. Without the %check section, cmockery2
would have been released and not been able to have been used. This is
why cmockery2 is set in the "BuildRequires" section.
Awesome!, now it make perfect sense to run these units tests during RPM
building. Thanks Luis.
On 07/22/2014 07:34 AM, Lalatendu Mohanty wrote:
On 07/22/2014 04:35 PM, Luis Pabón wrote:
I understand that when something is new and different, it is most
likely blamed for anything wrong that happens. I highly propose
that we do not do this, and instead work to learn more about the tool.
Cmockery2 is a tool that is important as the compiler. It provides
an extremely easy method to determine the quality of the software
after it has been constructed, and therefore it has been made to be
a requirement of the build. Making it optional undermines its
importance, and could in turn make it useless.
Hey Luis,
Th intention was not to undermine or give less importance to
Cmockery2. Sorry if it looked like that.
However I was thinking from a flexibility point of view. I am
assuming in future, it would be part of upstream regression test
suite. So each patch will go through full unit testing by-default. So
when somebody is creating RPMs from pristine sources, we should be
able to do that without Cmockery2 because the tests were already ran
through Jenkins/gerrit.
The question is do we need Cmockery every-time we compile glusterfs
source? if the answer is yes, then I am fine with current code.
Cmockery2 is available for all supported EPEL/Fedora versions. For
any other distribution or operating system, it takes about 3 mins to
download and compile.
Please let me know if you have any other questions.
- Luis
On 07/22/2014 02:23 AM, Lalatendu Mohanty wrote:
On 07/21/2014 10:48 PM, Harshavardhana wrote:
Cmockery2 is a hard dependency before GlusterFS can be compiled in
upstream master now - we could make it conditional
and enable if necessary? since we know we do not have the cmockery2
packages available on all systems?
+1, we need to make it conditional and enable it if necessary. I
am also not sure if we have "cmockery2-devel" in el5, el6. If not
Build will fail.
On Mon, Jul 21, 2014 at 10:16 AM, Luis Pabon <lpa...@redhat.com>
wrote:
Niels you are correct. Let me take a look.
Luis
-----Original Message-----
From: Niels de Vos [nde...@redhat.com]
Received: Monday, 21 Jul 2014, 10:41AM
To: Luis Pabon [lpa...@redhat.com]
CC: Anders Blomdell [anders.blomd...@control.lth.se];
gluster-devel@gluster.org
Subject: Re: [Gluster-devel] Cmockery2 in GlusterFS
On Mon, Jul 21, 2014 at 04:27:18PM +0200, Anders Blomdell wrote:
On 2014-07-21 16:17, Anders Blomdell wrote:
On 2014-07-20 16:01, Niels de Vos wrote:
On Fri, Jul 18, 2014 at 02:52:18PM -0400, Luis Pabón wrote:
Hi all,
A few months ago, the unit test framework based on
cmockery2 was
in the repo for a little while, then removed while we
improved the
packaging method. Now support for cmockery2 (
http://review.gluster.org/#/c/7538/ ) has been merged into
the repo
again. This will most likely require you to install
cmockery2 on
your development systems by doing the following:
* Fedora/EPEL:
$ sudo yum -y install cmockery2-devel
* All other systems please visit the following page:
https://github.com/lpabon/cmockery2/blob/master/doc/usage.md#installation
Here is also some information about Cmockery2 and how to use it:
* Introduction to Unit Tests in C Presentation:
http://slides-lpabon.rhcloud.com/feb24_glusterfs_unittest.html#/
* Cmockery2 Usage Guide:
https://github.com/lpabon/cmockery2/blob/master/doc/usage.md
* Using Cmockery2 with GlusterFS:
https://github.com/gluster/glusterfs/blob/master/doc/hacker-guide/en-US/markdown/unittest.md
When starting out writing unit tests, I would suggest writing
unit
tests for non-xlator interface files when you start. Once you
feel
more comfortable writing unit tests, then move to writing
them for
the xlators interface files.
Awesome, many thanks! I'd like to add some unittests for the
RPC and
NFS
layer. Several functions (like ip-address/netmask matching for
ACLs)
look very suitable.
Did you have any particular functions in mind that you would
like to
see
unittests for? If so, maybe you can file some bugs for the
different
tests so that we won't forget about it? Depending on the
tests, these
bugs may get the EasyFix keyword if there is a clear
description and
some pointers to examples.
Looks like parts of cmockery was forgotten in glusterfs.spec.in:
# rpm -q -f `which gluster`
glusterfs-cli-3.7dev-0.9.git5b8de97.fc20.x86_64
# ldd `which gluster`
linux-vdso.so.1 => (0x00007ffff4dfe000)
libglusterfs.so.0 => /lib64/libglusterfs.so.0
(0x00007fe034cc4000)
libreadline.so.6 => /lib64/libreadline.so.6
(0x00007fe034a7d000)
libncurses.so.5 => /lib64/libncurses.so.5
(0x00007fe034856000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fe03462c000)
libgfxdr.so.0 => /lib64/libgfxdr.so.0 (0x00007fe034414000)
libgfrpc.so.0 => /lib64/libgfrpc.so.0 (0x00007fe0341f8000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fe033e8f000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe033c79000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe033971000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe03376d000)
libcmockery.so.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0
(0x00007fe03354f000)
libcrypto.so.10 => /lib64/libcrypto.so.10
(0x00007fe033168000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe032da9000)
libcmockery.so.0 => not found
libcmockery.so.0 => not found
libcmockery.so.0 => not found
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe032b82000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe0351f1000)
Should I file a bug report or could someone on the fast-lane
fix this?
My bad (installation with --nodeps --force :-()
Actually, I was not expecting a dependency on cmockery2. My
understanding was that only some temporary test-applications
would be
linked with libcmockery and not any binaries that would get
packaged in
the RPMs.
Luis, could you clarify that?
Thanks,
Niels
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
