Change Details

(I feel like this was already filed, but I can't find the dupe. Feel free to merge this into the previous task if you've got better search foo than I do.) We already provide a "lookside" to composer in order to run parsoid on scandium against a specific commit of Parsoid, instead of whatever the train build includes. But sometimes the latest parsoid depends on a new library which has not yet been train-deployed. We need a similar trick in order to ensure that the round-trip testing runs Parsoid with a specific git tag of mediawiki-vendor as well as a specific git tag of Parsoid, in order to avoid a two week release delay (upgrade library, wait a week for library to ride the train, then commit corresponding fixes to parsoid and rt-test them, wait a week for that to ride the train, and if any problems are found during rt-testing, loop back to the beginning and start over).

(I feel like this was already filed, but I can't find the dupe. Feel free to merge this into the previous task if you've got better search foo than I do.) We already provide a "lookside" to composer in order to run parsoid on scandium against a specific commit of Parsoid, instead of whatever the train build includes. But sometimes the latest parsoid depends on a new library which has not yet been train-deployed. We need a similar trick in order to ensure that the round-trip testing runs Parsoid with a specific git tag of mediawiki-vendor as well as a specific git tag of Parsoid, in order to avoid a two week release delay (upgrade library, wait a week for library to ride the train, then commit corresponding fixes to parsoid and rt-test them, wait a week for that to ride the train, and if any problems are found during rt-testing, loop back to the beginning and start over). EDIT: when we change code in core (ie, stuff in `includes/parser/Parsoid`) we also can't run regression testing until that core code rides the train fully. So the task description should perhaps be amended to include "latest git HEAD of mediawiki-core" as well. But as discussed below (T298046#7785777) a partial solution would be to run regression tests against the latest wmf.X version *regardless of domain*, so that we can start regression testing as soon as the train rolls out to group.0, instead of having to wait until it reaches group.2.

(I feel like this was already filed, but I can't find the dupe. Feel free to merge this into the previous task if you've got better search foo than I do.) We already provide a "lookside" to composer in order to run parsoid on scandium against a specific commit of Parsoid, instead of whatever the train build includes. But sometimes the latest parsoid depends on a new library which has not yet been train-deployed. We need a similar trick in order to ensure that the round-trip testing runs Parsoid with a specific git tag of mediawiki-vendor as well as a specific git tag of Parsoid, in order to avoid a two week release delay (upgrade library, wait a week for library to ride the train, then commit corresponding fixes to parsoid and rt-test them, wait a week for that to ride the train, and if any problems are found during rt-testing, loop back to the beginning and start over). EDIT: when we change code in core (ie, stuff in `includes/parser/Parsoid`) we also can't run regression testing until that core code rides the train fully. So the task description should perhaps be amended to include "latest git HEAD of mediawiki-core" as well. But as discussed below (T298046#7785777) a partial solution would be to run regression tests against the latest wmf.X version *regardless of domain*, so that we can start regression testing as soon as the train rolls out to group.0, instead of having to wait until it reaches group.2.