Now we can assert that our libraries aren't screwed with, we should.
[Not really RL, but nowhere better to put it?]
Now we can assert that our libraries aren't screwed with, we should.
[Not really RL, but nowhere better to put it?]
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/core | master | +54 -8 | resources: Add caching for faster runs and offline use |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T203694 Run ForeignResourceManager verification on MediaWiki core commits | |||
Resolved | Krinkle | T216620 Add error detection to HTTP fetch in foreign resources checker before gzipping |
Yeah, sounds good to me!
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:
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
Change 498737 merged by jenkins-bot:
[mediawiki/core@master] resources: Add caching for faster runs and offline use
Actual Jenkins integration still to be done later.
Could be a PHPUnit structure test, or a separate job. Not sure yet.