About the Serf test failure: Just confirmed with curl that we should update the expectations. The page has moved and its content has changed, but https fetching is working, which is what the test is trying to affirm. So ignoring the test failure is OK.
Otto On Sat, Apr 13, 2019 at 9:18 PM Otto van der Schaaf <[email protected]> wrote: > Here's the failing Serf test: > [ RUN ] SerfUrlAsyncFetcherTest.TestHttpsSucceedsForGoogleCom > pagespeed/system/serf_url_async_fetcher_test.cc:410: Failure > Value of: response_headers(index)->status_code() > Actual: 302 > Expected: HttpStatus::kOK > Which is: 200 > pagespeed/system/serf_url_async_fetcher_test.cc:414: Failure > Value of: contents(index).substr(0, content_starts_[index].size()) > Actual: "<HTML><HEAD><me" > Expected: content_starts_[index] > Which is: "<!DOCTYPE html>" > > I could not repro the TestHistogramRender test failure. > [1] EXPECT_TRUE(Contains(html_graph, "25.0%")); > > But after thinking about it, what I think has happened is that while I was > starting out, I created gce vm with a dutch locale. > I didn't go in a straight line from a to b. > I think the dutch locale gets us "25,0%" instead of "25.0%". > The expectations that wouldn't be affected by this passed, which I think > nails it down to that. > > [1] > https://github.com/apache/incubator-pagespeed-mod/blob/b4bf44cc56d8bbf17494c540dfb6ef20dfcf5073/pagespeed/kernel/sharedmem/shared_mem_statistics_test_base.cc#L410 > > Otto > > On Sat, Apr 13, 2019 at 4:47 PM Otto van der Schaaf <[email protected]> > wrote: > >> Great! I'm digging up more info on the errors that the disabled tests >> produced, I will share them here once I have them. >> >> As for testing, yes, the release scripts run tests before creating the >> artifacts, and then they also test the actual artifacts they produce. >> The release-process testing is a more thorough compared to what is done >> in CI, probably because of CI resource contstraints. >> This may be why these errors didn't emerge earlier. >> >> Otto >> >> On Sat, Apr 13, 2019 at 4:27 PM Joshua Marantz >> <[email protected]> wrote: >> >>> I've installed it on my desktop and seems to be working through a manual >>> smoke-test on an older copy I had handy of the mod_pagespeed_examples >>> tree, >>> including rendering of histograms on the admin page. LGTM! >>> >>> I just want to double-check one thing though for completeness: in the >>> past, >>> when creating artifacts, the script installed the artifacts locally and >>> ran >>> a suite of system-tests against the installed module. That is still part >>> of >>> the process, right? >>> >>> >>> >>> On Sat, Apr 13, 2019 at 10:05 AM Joshua Marantz <[email protected]> >>> wrote: >>> >>> > Thanks for doing this Otto! It'll be great to get the updates for this; >>> > there are some important long-pending bug fixes in this cut. >>> > >>> > I agree about the serf google.com test failures probably not being >>> > significant, but can you paste them here? >>> > >>> > The histogram one is more surprising. Can you paste that one too? >>> > >>> > Meanwhile, I'll try to install your binary on my system. >>> > >>> > On Sat, Apr 13, 2019 at 9:53 AM Otto van der Schaaf < >>> [email protected]> >>> > wrote: >>> > >>> >> Hi all, >>> >> >>> >> I have a new potential RC staged here: >>> >> http://home.apache.org/~oschaaf/mod_pagespeed/1.14.36.1-rc1/ >>> >> This has: >>> >> - the mandatory source tarball >>> >> - x64 .deb/.rpm files + a psol binary source tarball. I feel we should >>> >> offer these unofficially as a project. >>> >> >>> >> I signed all the artifacts. It would be great if someone could give >>> them a >>> >> spin. >>> >> >>> >> *Important: I had to disable two automated tests to get to the release >>> >> artifacts:* >>> >> - A serf test against google.com. I'm not concerned by this one, it >>> just >>> >> seems that google.com changes the way it responds. >>> >> - TestHistogramRender seems to have rotted and fails, and I'm not >>> sure how >>> >> that can be. >>> >> I *think* this isn't blocking, and I suspect this might be related to >>> >> recent changes related to the redis-cache. >>> >> But that is a guess, and this needs proper root cause analysis before >>> we >>> >> can confidently proceed with next steps from >>> >> http://incubator.apache.org/guides/releasemanagement.html >>> >> I'll try to figure why this test broke this week and update this >>> thread to >>> >> see if a release-respin is warranted. >>> >> >>> >> *Change list compiled analysing the commit history (excluding doc >>> changes >>> >> and changes to comply with ASF incubation policy):* >>> >> - Add cPanel EasyApache 4 RPM build support >>> >> - Add support for specifying a TTL for redis keys >>> >> - Fix mismatch between decompression and headers >>> >> - Handle Apache >2.4 mod_authz_host >>> >> - Redis: Use Redis DB-Index when computing the SystemCache lookup key >>> >> - CentOS: changed urls for sl devtoolset repo >>> >> - Add <code> to sensitive tags in collapse_whitespace_filter. >>> >> - Upgrade libwebp to 0.6.1 >>> >> - Upgrade grpc library to version 1.6.0 >>> >> - Upgrade libpng library to version 1.6 >>> >> - Fix leak in srcset test: add call to Detach() >>> >> - Fix for Worker process exited on signal 11 (core dump) >>> >> >>> >> Cheers, >>> >> >>> >> Otto >>> >> >>> > >>> >>
