Page MenuHomePhabricator

MEDIAWIKI_URL may be set to incorrect value in mwext-mw-selenium job
Closed, DeclinedPublic




I've introduced a call to MediawikiApi::Client#get_wikitext in the step that's failing. The call fails with an error, of which the body suggests that /w/index.php doesn't exist.

Now, during Zuul cloner phase of the build, the MEDIAWIKI_URL environment variable is set to http://localhost:9412/jenkins-mwext-mw-selenium-9801/index.php/. Consequently, the call to #get_wikitext is requesting http://localhost:9412/jenkins-mwext-mw-selenium-9801/index.php//w/index.php, which will obviously fail.

Is it that my change (rEMFR5220b0f0ce28) is wrong? Is it that MEDIAWIKI_URL is wrong and needs to be fixed? Or is it that MediawikiApi::Client#get_wikitext is wrong?

Using mediawiki_api 0.7.0
Using mediawiki_selenium 1.7.2

Event Timeline

phuedx created this task.Sep 7 2016, 12:47 PM
Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptSep 7 2016, 12:47 PM
zeljkofilipin triaged this task as Medium priority.
phuedx updated the task description. (Show Details)Sep 7 2016, 12:52 PM

^ I mustn't disregard the possibility (strong likelihood) that I've done something wrong.

#get_wikitext works fine when targeting my local mediawiki-vagrant machine.

$ irb

irb(main):001:0> require "mediawiki_api"
=> true

irb(main):002:0> client = ""
=> #<MediawikiApi::Client:0x007fa2fa61a888 @cookies=#<HTTP::CookieJar:0x007fa2fa61a860 @store=#<HTTP::CookieJar::HashStore:0x007fa2fa5f3af8 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Thread::Mutex:0x007fa2fa5f3a08>, @logger=nil, @gc_threshold=150, @jar={}, @gc_index=0>>, @conn=#<Faraday::Connection:0x007fa2fa5f3788 @parallel_manager=nil, @headers={"User-Agent"=>"Faraday v0.9.2"}, @params={}, @options=#<Faraday::RequestOptions (empty)>, @ssl=#<Faraday::SSLOptions (empty)>, @default_parallel_manager=nil, @builder=#<Faraday::RackBuilder:0x007fa2fa5f33c8 @handlers=[Faraday::Request::Multipart, Faraday::Request::UrlEncoded, Faraday::CookieJar, FaradayMiddleware::FollowRedirects, Faraday::Adapter::NetHttp]>, @url_prefix=#<URI::HTTP>, @proxy=nil>, @logged_in=false, @tokens={}>

irb(main):019:0> client.get_wikitext("Main Page").body
=> "<!--\n    If you are reading the source wikitext of the main page:\n        This page is created by Vagrant, but it is safe to do changes by editing it.\n        Automatic updates will happen via [[Template:Main Page]].\n\n    If you are reading puppet/modules/mediawiki/files/\n        DO NOT MODIFY THIS FILE! Updates would cause all local changes to be overwritten.\n        If you want to add content to the main page, use instead.\n-->\n{{Main Page}}"

Running failed scenario (diff.feature:5) on master runs fine when targeting my local mediawiki-vagrant machine.

$ bundle exec cucumber features/diff.feature:5
@chrome @firefox @vagrant
Feature: Page diff

  @smoke @editing @integration
  Scenario: Added and removed content                            # features/diff.feature:5
    Given I am logged into the mobile website                    # features/step_definitions/common_steps.rb:28
    And the page "Selenium diff test 3" has the following edits: # features/step_definitions/editor_steps.rb:1
      | text    |
      | ABC DEF |
      | ABC GHI |
    When I am on the "Selenium diff test 3" page                 # features/step_definitions/common_steps.rb:48
    And I click on the history link in the last modified bar     # features/step_definitions/common_article_steps.rb:20
    And I open the latest diff                                   # features/step_definitions/special_history_steps.rb:5
    Then I should see "GHI" as added content                     # features/step_definitions/diff_steps.rb:1
    And I should see "DEF" as removed content                    # features/step_definitions/diff_steps.rb:5

1 scenario (1 passed)
7 steps (7 passed)

Everything runs fine locally even with commit 308956, the problem must be related to mwext-mw-selenium job.

mwext-mw-selenium in mediawiki-extensions.yaml

# Generic mw-selenium job for extensions.
- job:
    name: 'mwext-mw-selenium'
    node: contintLabsSlave && UbuntuTrusty
    concurrent: true
     - zuul
     - prepare-mediawiki-zuul-project
     - zuul-cloner:
         projects: mediawiki/skins/Vector
     - mw-selenium
     - mw-selenium-cleanup
     - localhost-cleanup
     - mw-teardown-mysql
     - archive-log-dir
      daysToKeep: 15
 artifactDaysToKeep: 3

mw-selenium in macro.yaml

# mw-selenium
# Run MW-Selenium tests that are marked with the @integration tag against a
# local instance of MediaWiki. All setup of intial state for these kinds of
# tests should be done by the test suite via the API, including creation of
# the test user.
# - tests-dir: Parent of the `features` directory. Usually `tests/browser`.
# ALWAYS pair with 'localhost-cleanup'
# ALWAYS pair with 'mw-selenium-cleanup'
- builder:
    name: mw-selenium-with-dir
     - prepare-localhost
     - bundle-with-options:
        initialization: '/srv/deployment/integration/slave-scripts/bin/'
        command: |
          cucumber --color --tags @integration --tags ~@skip --format pretty \
            --format junit --out $WORKSPACE/log/junit
        dir: '{tests-dir}'
        bundler-version: ''

# Run MW-Selenium tests located in a standard location, `tests/browser` beneath
# the MW extension directory. Note that EXT_NAME is set by
# zuul/
# ALWAYS pair with 'localhost-cleanup'
# ALWAYS pair with 'mw-selenium-cleanup'
- builder:
    name: mw-selenium
     - mw-selenium-with-dir:
 tests-dir: 'src/extensions/$EXT_NAME/tests/browser'

#!/bin/bash -eu

. /srv/deployment/integration/slave-scripts/bin/

mkdir -p "$TMPDIR_FS"
mkdir -p "$TMPDIR_REGULAR"

# Append the MW installation's LocalSettings.php with the contents of
# tests/browser/LocalSettings.php. Note that this setup script requires that
# the current working directory already be the appropriate `tests/browser`
# directory.
if [ -f LocalSettings.php ]; then
  cat LocalSettings.php >> "$MW_INSTALL_PATH/LocalSettings.php"

The job clone the repos under $WORKSPACE/src then we publish that to Apache with a symlink:

ln -s $WORKSPACE/src /srv/localhost-worker/jenkins-mwext-mw-selenium-9801

The curl command reflect that:

curl http://localhost:9412/jenkins-mwext-mw-selenium-9801/index.php/Special:BlankPage

Then when configuring the env variables the job does:

export MEDIAWIKI_URL=http://localhost:9412/jenkins-mwext-mw-selenium-9801/index.php/

note the trailing slash in the URL while for the API URL we do do not have a trailing slash:

export MEDIAWIKI_API_URL=http://localhost:9412/jenkins-mwext-mw-selenium-9801/api.php

I have no idea if the trailing slash in MEDIAWIKI_URL is intentional or not. I can totally imagine the ruby code making an assumption that if it ends with a slash, then the /w/index.php has to be appended and thus utterly fails.

Potentially the trailing slash is because MediaWiki has pathinfo enabled and that will trigger it. (Eg /index.php/Foobar is understood by MediaWiki has /index.php?title=Foobar. That would explain the trailing slash but I am rusty on that side.

Regarding the ruby call MediawikiApi::Client#get_wikitext shouldn't it use an API call and thus the MEDIAWIKI_API_URL instead? Cause rEMFR5220b0f0ce28 looks like it s doing API interactions and I dont see why we would screen crap over index.php.

hashar updated the task description. (Show Details)Sep 9 2016, 10:58 AM

#!/bin/bash -eu

# Xvfb barfs when trying to move xkb files across filesystems, so we must use
# /tmp for now
export SKIP_TMPFS=1

. /srv/deployment/integration/slave-scripts/bin/

# Selenium requires the chromedriver binary to be found in our PATH
for path in /usr/lib/chromium-browser /usr/lib/chromium; do
  if test -d "$path"; then
    export PATH="$PATH:$path"

# Let MW-Selenium setup/teardown an isolated Xvfb on a display between 70-90
# for this build
export HEADLESS=true

export MEDIAWIKI_ENVIRONMENT=integration

def get_wikitext(title)
  @conn.get '/w/index.php', action: 'raw', title: title


def get_wikitext(title)
  @conn.get '/w/index.php', action: 'raw', title: title

That method has been added in April 2014 apparently for CirrusSearch by

Example usages:

Usage in CirrusSearch is the helper CirrusSearchApiHelper.get_page_text() also used by edit_page(). The later seems to still be used.

If that works on CirrusSearch, the url must be properly initialized there.


The only two places where #get_wikitext is used are:

CirrusSearch/tests/browser/features/support/cirrus_search_api_helper.rb: fetched_text = api.get_wikitext(title)
MobileFrontend/tests/browser/features/step_definitions/editor_steps.rb: expect(api.get_wikitext(page).body).to eq text

Change 309594 had a related patch set uploaded (by Zfilipin):
WIP Fix #get_wikitext

The problem is that #get_wikitext uses index.php's action=raw mode instead of the API.

309594 is an ugly hack, but it works (in this case), and it uses the API. It can probably be simpler or more robust (or both).

What should be done to properly resolve the problem:

  • update #get_wikitext to use the API
  • release new mediawiki_api Ruby gem with the fix
  • update mwext-mw-selenium Jenkins job to use a Rake target (rake integration?) instead of executing Cucumber directly
  • since there is no such target, it should be added to mediawiki_selenium gem
  • new version of the gem should be released
โ€ข jhobs changed the status of subtask T144300: Page diff test failing from Open to Stalled.Sep 12 2016, 4:27 PM

Change 309594 abandoned by Zfilipin:
WIP Fix #get_wikitext

An experiment

Change 311195 had a related patch set uploaded (by Bmansurov):
Beta: Allow displaying Related Articles in the footer

Change 311197 had a related patch set uploaded (by Bmansurov):
Blacklist minerva from showing Related Articles in the footer

Change 311197 merged by jenkins-bot:
Blacklist minerva from showing Related Articles in the footer

Mentioned in SAL (#wikimedia-operations) [2016-09-21T23:31:35Z] <dereckson@tin> Synchronized wmf-config/InitialiseSettings.php: Blacklist minerva from showing Related Articles in the footer (T144912, currently no-op) (duration: 00m 49s)

Mentioned in SAL (#wikimedia-operations) [2016-09-21T23:32:38Z] <dereckson@tin> Synchronized wmf-config/CommonSettings.php: Blacklist minerva from showing Related Articles in the footer (T144912, currently no-op) (duration: 00m 47s)

zeljkofilipin removed zeljkofilipin as the assignee of this task.Sep 28 2016, 2:12 PM
zeljkofilipin added a subscriber: zeljkofilipin.
Jdlrobson added a subscriber: Jdlrobson.

I'm a little confused. What's the state of this bug?

The state is that I did not have the time to work on this yet :(

This is what needs to be done: T144912#2628210

zeljkofilipin lowered the priority of this task from Medium to Low.May 29 2017, 10:30 AM
zeljkofilipin closed this task as Declined.Nov 7 2017, 3:10 PM

Unlikely to ever be resolved because of T139740: Port Selenium tests from Ruby to Node.js.