Page MenuHomePhabricator

Run ForeignResourceManager verification on MediaWiki core commits
Open, MediumPublic

Description

Now we can assert that our libraries aren't screwed with, we should.

[Not really RL, but nowhere better to put it?]

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added a project: Performance-Team. · View Herald TranscriptSep 6 2018, 4:57 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Krinkle added a subscriber: Krinkle.Sep 6 2018, 5:06 PM

Yeah, sounds good to me!

  • The urls are expected to be immutable. The main value we want to get from verifying is to assert that the checksum in our YAML is correct for the given url, and that the extracted files from the remote resource match what was checked into our Git repo. It's less important to verify that the remote copy hasn't changed.
  • Without a cache, the job would likely be quite slow. Might be fine if it's a separate job in parallel, but not if adding to the main job.
  • Without a cache, the job would be more likely to fail due to random upstream/network issues.
  • Regarding cache, probably we can use Castor for this? Alternatively, some generic Squid/http proxy might also work.
Krinkle triaged this task as Medium priority.Sep 7 2018, 1:15 AM
Krinkle moved this task from Inbox to Accepted Enhancement on the MediaWiki-ResourceLoader board.
Krinkle moved this task from Inbox to Checkers on the MediaWiki-Core-Testing board.
Legoktm added a subscriber: Legoktm.Sep 7 2018, 1:35 AM

Is there a reason this needs to be something separate and can't be a standard PHPUnit test?

Krinkle added a comment.EditedSep 7 2018, 2:09 AM

Is there a reason this needs to be something separate and can't be a standard PHPUnit test?

The "this" as the maintenance script, yes, because it's not (just) a test.

The "this" as the solution for this task to run the verify step in CI, no, that doesn't need to be separate. But, there are considerations that might motivate one to run it separately. Specifically:

[..]

  • Without a cache, the job would likely be quite slow. [..]
  • Without a cache, the job would be more likely to fail due to random upstream/network issues.

But yes, if we do use a cache, and make it work fast, it should be fine to add to the "big" quibble job. But, if we can not make it fast, and/or if the cache is hard to get to work within PHPUnit, then it might make sense to run from a separate job in a way that just invokes the "verify" command from bash.

Change 498737 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] resources: Add caching for faster runs and offline use

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

Change 498737 merged by jenkins-bot:
[mediawiki/core@master] resources: Add caching for faster runs and offline use

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

Actual Jenkins integration still to be done later.

Could be a PHPUnit structure test, or a separate job. Not sure yet.

Krinkle renamed this task from Run `maintenance/resources/manageForeignResources.php verify` as a test on MediaWiki core to Run ForeignResourceManager verification on MediaWiki core commits.Apr 5 2019, 3:57 PM