[gnutls-devel] valgrind-tests vs full-test-suite

Alon Bar-Lev alon.barlev at gmail.com
Tue Mar 14 14:09:55 CET 2017

On 14 March 2017 at 15:01, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 14 March 2017 at 14:41, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Tue, Mar 14, 2017 at 8:41 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> >>> This actually disables valgrind in non-git but I do not see any reason
>> >>> to do so as valgrind is supported in some other tests. If I disable
>> >>> the full-tests-suite then I can enjoy valgrind extra tests.
>> >>> Any reason why we condition this?
>> >>
>> >> If I remember well, the reason this was introduced was to avoid test
>> >> suite failures due to leaks or other issues in unrelated libraries on
>> >> the released version. E.g., if you try to compile the latest release
>> >> of gnutls in a system which has a libc with a leak, you wouldn't have
>> >> the test suite fail because of that.
>> >
>> > The valgrind tests may be enabled or disabled.
>> That's true but we have them enabled by default, so builds would fail
>> for that reason and that would create more noise in the list.
>> > In release tarball there is no full-suite.
>> > The result is that valgrind cannot be enabled unless the non-existence
>> > full-suite is disabled...
>> > So I do not think this logic is required.
>> That's true, but I am afraid of the issue above (when this was added
>> was specifically to avoid such reports from the list). It should be
>> combined with another change that makes valgrind not to run by default
>> on releases.
> Hi,
> Can we disable this by default and enable it explicitly in all ci jobs?
> Or can we add another flag that is disabled by default and when
> enabled will not touch the VALGRIND?
> Alon

I can disable these by default if it is a release tarball (no
full-test-suite), maybe this is the best.

More information about the Gnutls-devel mailing list