Last modified: 2014-10-15 20:27:51 UTC
An Echo browser test trying to create an account failed with 503 Service unavailable. That's understandable, but the indication of failure was buried in the HTML of the WMF error page. It would be great if the mediawiki_api gem noticed the HTTP request error status and failed with e.g. "create_account API HTTP request failure: <Status line>" I'm confused because Gerrit change #157300 fixed bug 70193 "Client now throws an HttpError when handling HTTP responses", but the check raise HttpError, response.status if response.status >= 400 seems missing from mediawiki_api-0.2.1 in this CI run and my local .rvm gem. The failure was in <https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/105/consoleFull> The line that went wrong is: on(APIPage).client.create_account(username, ENV["MEDIAWIKI_PASSWORD"]) The console output is ... 05:35:08 Given I am logged in as a new user # features/step_definitions/notifications_steps.rb:60 05:35:08 757: unexpected token at '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/2002/REC-xhtml1-20020801/DTD/xhtml1-transitional.dtd"> ... entire text of the HTML error page ... 100s of lines later: 05:35:09 <!-- Technical details of the error; shows all the time, with any language --> 05:35:09 <div class="TechnicalStuff"> 05:35:09 <bdo dir="ltr"> 05:35:09 503 Service Temporarily Unavailable 05:35:09 </bdo> 05:35:09 <div id="AdditionalTechnicalStuff"></div> 05:35:09 </div> ... 100s more lines 05:35:09 </html> 05:35:09 05:35:09 ' (JSON::ParserError) 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/json-1.8.1/lib/json/common.rb:155:in `parse' 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/json-1.8.1/lib/json/common.rb:155:in `parse' 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/response.rb:85:in `response_object' 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/response.rb:46:in `data' 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/client.rb:51:in `create_account' 05:35:09 /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/client.rb:58:in `create_account' 05:35:09 /mnt/jenkins-workspace/workspace/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/tests/browser/features/step_definitions/common_steps.rb:48:in `block in <top (required)>'
Change 166679 had a related patch set uploaded by Dduvall: Releasing minor version 0.3.0 https://gerrit.wikimedia.org/r/166679
Change 166679 merged by jenkins-bot: Releasing minor version 0.3.0 https://gerrit.wikimedia.org/r/166679
Built and released the gem. Running `bundle update mediawiki_api` in your tests/browser directory should update you to 0.3.0.
S, did the change solve the problem?
I renamed api.php locally, did bundle update, ran Echo's features/notifications_userrights.feature , and it quickly failed with unexpected HTTP response (404) (MediawikiApi::HttpError) ./features/step_definitions/notifications_steps.rb:8:in `clear_notifications' \o/ ! The next problem is getting WMF's CI to use the new version. The latest Echo run https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/108/consoleFull still uses old version 0.2.1, e.g. /mnt/jenkins-workspace/workspace/gems/gems/mediawiki_api-0.2.1/lib/mediawiki_api/response.rb:85:in `response_object' So I guess we have to go into 13 extensions using mediawiki_api, `bundle update`, and check in their new Gemfile.locks. I dunno if there's a way to automate this. I filed a separate bug 72090
