[openssl-dev] who wants to fix travis builds?

Alessandro Ghedini alessandro at ghedini.me
Tue Sep 29 12:48:37 UTC 2015


On Mon, Sep 28, 2015 at 08:49:12pm +0200, Andy Polyakov wrote:
> > FWIW, Travis CI allows you to define specific builds to be "non-fatal". The
> > failures would still be listed but they wouldn't affect the general state. See
> > for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last
> > two builds fail but are in the "Allowed Failures" section and the general build
> > state is green).
> > 
> > So we could add another debug-only configuration that is not allowed to fail,
> > and mark the current debug+strict-warnings builds on mingw as non-fatal. This
> > way the non-fatal builds are still run and someone can have a look at them
> > and try to fix them if they want.
> 
> --strict-warnings imply -Werror and then it's rendered all-or-nothing. I
> mean you can't ignore -Werror failure, because binary code is not
> generated. On the other hand generating warnings without -Werror is
> hardly meaningful in CI scenario, because you don't look at log unless
> there is problem. So it makes sense to bet on -Werror only if one is
> confident about it being representative, and the problem is that there
> is no guarantee that it's universally representative. Hence it can be
> exercised only is specific cases.

I think we are talking about two different things. What I meant is that due to
the debug+strict-warnings+mingw failures, the "global" state on Travis is shown
as "failed" https://travis-ci.org/openssl/openssl

To fix this, we could either drop those builds completely, or just mark them as
"Allowed Failures": they are still run, but even if they fail the Travis state
is not shown as "failed". But to do this we would have to add additional
debug-only (without --strict-warnings) builds that are *not* allowed to fail.

> >> As for running tests in the context of query, i.e. mingw cross-compilation on
> >> Linux. It actually was possible to perform under 'wine' before and surely can
> >> be fixed now. Is 'wine' an option in this case?
> > 
> > I don't know if it actually works, but we can configure Travis CI to install
> > wine before starting the builds.
> 
> Can you test and figure out? As implied, currently new 'make test'
> doesn't work with 'wine' yet, but you can replace 'make test' with e.g.
> test/sha1test.exe alone. Just to figure out if it works. It might happen
> that it's not sufficient to simply install package, one might have to
> perform per-user config prior Win32 .exes can be executed.

It works!!! Well, sort of. It requires 3 patches [0] (including the changes to
the Travis CI config) and there are 3 or so tests that fail (see log at [1]),
but it's basically doable.

Cheers

[0] https://github.com/ghedo/openssl/commits/mingwci
[1] https://travis-ci.org/ghedo/openssl/jobs/82727489
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150929/b698dfed/attachment-0001.sig>


More information about the openssl-dev mailing list