Page MenuHomePhabricator

Reorg of code layout in Parsoid module breaks l10nupdate build in beta and halts scap
Closed, ResolvedPublic

Description

beta-scap-eqiad has been failing since the 09-Sep-2014 23:45:52 run.

Don't know where to look for the log file.


Version: unspecified
Severity: major

Details

Reference
bz70696

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:51 AM
bzimport added a project: Deployments.
bzimport set Reference to bz70696.
bzimport added a subscriber: Unknown Object (MLST).

The problem this time is something to do with the l10nupdate phase as shown in the scap jenkins job log https://integration.wikimedia.org/ci/job/beta-scap-eqiad/21024/console

Running manually says this:

$ mwscript mergeMessageFileList.php --wiki="eowiki" --list-file="/a/common/wmf-config/extension-list"
PHP Notice: Undefined index: REQUEST_URI in /mnt/srv/scap-stage-dir/wmf-config/CommonSettings.php on line 2481

Notice: Undefined index: REQUEST_URI in /mnt/srv/scap-stage-dir/wmf-config/CommonSettings.php on line 2481
Extension /mnt/srv/scap-stage-dir/php-master/extensions/Parsoid/php/Parsoid.php doesn't exist
Some files are missing (see above). Giving up.

This seems to have been caused by If36cd0151914bbe8cec69171a3894e6ad11bc5d8 being merged without an associated config change.

I see that I837fe40e493f32a787987ad6eb9ce0625dfbfab6 has attempted to make the appropriate config change and that commit is checked out where I expect it to be on deployment-bastion. Continuing to investigate.

The problem is right there in the command that scap is running: --list-file="/a/common/wmf-config/extension-list"

Scap is not using extension-list-labs but instead using the prod list. Looks like this is a scap bug.

(In reply to Bryan Davis from comment #4)

The problem is right there in the command that scap is running:
--list-file="/a/common/wmf-config/extension-list"

Scap is not using extension-list-labs but instead using the prod list. Looks
like this is a scap bug.

Error is at https://github.com/wikimedia/mediawiki-tools-scap/blob/master/scap/tasks.py#L426. This however seems to be the historical behavior as well as show in the older bash implementation https://github.com/wikimedia/mediawiki-tools-scap/blob/46d216953ad139506dd8b8e5dcd49fed7b980947/bin/mw-update-l10n#L85.

Change 159670 had a related patch set uploaded by BryanDavis:
Use realm specific extension-list to generate l10n

https://gerrit.wikimedia.org/r/159670

Using a realm specific file doesn't work because the target file is "extension-list-labs" and not "extension-list.labs"

And extension-list-labs is pretty obviously meant to be additive to extension-list ans not a replacement.

Change 159670 abandoned by BryanDavis:
Use realm specific extension-list to generate l10n

Reason:
extension-list-labs is pretty obviously meant to be an addition to extension-list and not a replacement.

https://gerrit.wikimedia.org/r/159670

(In reply to Bryan Davis from comment #3)

I see that I837fe40e493f32a787987ad6eb9ce0625dfbfab6 has attempted to make
the appropriate config change and that commit is checked out where I expect
it to be on deployment-bastion. Continuing to investigate.

It turns out that this change is not the right thing to do. extension-list-labs is for extensions that are not in production rather than a realm specific version of the extension-list file.

I think the fix for this is to revert both If36cd0151914bbe8cec69171a3894e6ad11bc5d8 and I837fe40e493f32a787987ad6eb9ce0625dfbfab6 and talk to Reedy about how to actually rearrange the layout of an extension safely.

Looks like Sam has fixed this by merging Idea5db96fba68d50d29ca31678cf6e26229c56db which I noticed last night but didn't want to merge at 23:15 local time. ;)

See https://integration.wikimedia.org/ci/job/beta-scap-eqiad/21091/console for working run of scap.