Re: AW: Integration tests running on Docker
Le 07/11/2019 à 11:31, Pluem, Ruediger, Vodafone Group a écrit :
C2 General
-Ursprüngliche Nachricht-
Von: Yann Ylavic
Gesendet: Donnerstag, 7. November 2019 11:19
An: httpd-dev
Betreff: Re: Integration tests running on Docker
On Wed, Nov 6, 2019 at 6:54 PM Joe Orton wrote:
Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
Debian-ish distro? I don't remember seeing this before but maybe it's
something
trivial? t/TEST output -
It seems to originate from r1868312.
I don't really understand this new test in mod_deflate (the one which
fails):
ok $original_str eq $deflated_str_q0;
Why would we expect a plain string to be equal to a deflated one,
Christophe?
I don't see how the failure depends on debian vs any other system
either.
Running t/modules/deflate.t on my debian, with this debugging patch:
```
Index: t/modules/deflate.t
===
--- t/modules/deflate.t (revision 1869498)
+++ t/modules/deflate.t (working copy)
@@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)
ok $original_str eq $inflated_str;
ok $original_str eq $deflated_str_q0;
+if (not $original_str eq $deflated_str_q0) {
+print "original: '$original_str'\n";
+print "deflated: '$deflated_str_q0'\n";
+}
my $resp = POST($server_inflate_uri, @inflate_headers,
content => "foo123456789012346");
if (have_min_apache_version("2.5")) {
```
I get (e.g.):
```
not ok 42
original: '
Some dummy content. Some dummy content. Some dummy content. Some dummy
content.
EOF
'
deflated: '
I suspect that $deflated_str_q0 is the result of the request with
Accept-Encoding: gzip;q=0
where mod_deflate actually should not gzip the response because of q=0.
Yeap, that's it
Regards
Rüdiger
AW: Integration tests running on Docker
C2 General > -Ursprüngliche Nachricht- > Von: Yann Ylavic > Gesendet: Donnerstag, 7. November 2019 11:32 > An: httpd-dev > Betreff: Re: Integration tests running on Docker > > On Thu, Nov 7, 2019 at 11:19 AM Yann Ylavic > wrote: > > > > Am I missing something? > > A brain or something like that :) > > Nevermind, I was just confused by the name of $deflated_str_q0, this > string isn't actually deflated because of q=0. > > Since this test passes on trunk, a backport is missing possibly? r1868314 Regards Rüdiger
AW: Integration tests running on Docker
C2 General
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic
> Gesendet: Donnerstag, 7. November 2019 11:19
> An: httpd-dev
> Betreff: Re: Integration tests running on Docker
>
> On Wed, Nov 6, 2019 at 6:54 PM Joe Orton wrote:
> >
> > Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
> > Debian-ish distro? I don't remember seeing this before but maybe it's
> something
> > trivial? t/TEST output -
>
> It seems to originate from r1868312.
>
> I don't really understand this new test in mod_deflate (the one which
> fails):
> ok $original_str eq $deflated_str_q0;
>
> Why would we expect a plain string to be equal to a deflated one,
> Christophe?
> I don't see how the failure depends on debian vs any other system
> either.
>
> Running t/modules/deflate.t on my debian, with this debugging patch:
> ```
> Index: t/modules/deflate.t
> ===
> --- t/modules/deflate.t (revision 1869498)
> +++ t/modules/deflate.t (working copy)
> @@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)
>
> ok $original_str eq $inflated_str;
> ok $original_str eq $deflated_str_q0;
> +if (not $original_str eq $deflated_str_q0) {
> +print "original: '$original_str'\n";
> +print "deflated: '$deflated_str_q0'\n";
> +}
> my $resp = POST($server_inflate_uri, @inflate_headers,
> content => "foo123456789012346");
> if (have_min_apache_version("2.5")) {
> ```
>
> I get (e.g.):
> ```
> not ok 42
> original: '
> Some dummy content. Some dummy content. Some dummy content. Some dummy
> content.
> EOF
> '
> deflated: '
AW: Integration tests running on Docker
C2 General > -Ursprüngliche Nachricht- > Von: Joe Orton > Gesendet: Mittwoch, 6. November 2019 10:53 > An: Apache HTTP Server Development List > Betreff: Re: Integration tests running on Docker > > On Tue, Nov 05, 2019 at 10:06:23AM +0100, Luca Toscano wrote: > > Basically what Joe did, but following what the Apache Arrow Project > > did. There is a little bit of repetition, but in theory with this > > config people are free to add tests for other OSes (osx, windows) and > > I will probably be able to add custom ones with Docker to see the > > difference in execution timings etc.. (Apache Arrow's test do use > > docker, I didn't see it a first). > > I haven't tried to follow all of what the Arrow .yml is doing (too much > Java ;) but moving some of the logic into the repo itself out of > .travis.yml seems like a good idea. e.g. moving all of script: into > something like ./test/travis_script_linux.sh or something for the Linux > based tests, does that make sense? > > This is working now - > > https://travis-ci.org/apache/httpd/builds > > and I guess it will work for forks and PRs too, haven't tried yet. > > Anybody feel free to extend, play, hack, whatever with the travis.yml, I > am no expert so may be doing something non-standard/wrong, feel free to > correct/improve ;) > > The jobs are quite quick but the queue time for the "apache" repos is > long (10+ minutes) before they get started. I guess it is doing > notifications to committers directly, but we won't find out until a job > fails? Maybe let's keep experimenting with this a bit longer and then > start sending mail to dev@ for state changes (exactly as buildbot does) > when it seems stable? +1. Thanks for taking care. Regards Rüdiger
