On 2013-10-12 7:27 AM, Niklas Laxström wrote:
2013/10/12 Daniel Friesen daniel@nadir-seen-fire.com:
I've been bothered for awhile by the mess we have in resources/jquery/ – 3rd party libraries, custom libraries we have to maintain, and directly MW related code using mediaWiki.* APIs all mixed together in the same directory. So I went and audited the .js we have inside resources/jquery/ and have wrote up an RFC on it:
https://www.mediawiki.org/wiki/Requests_for_comment/Isolate_custom_jQuery_li...
Thanks for doing the research. I recently came across this [1], but based on your writing it was just a tip of the iceberg.
-Niklas
That gives me a small extra idea. If we manage to go with one of my recommendations on integrating bower as the method of installing/updating the stuff we commit we might be able to integrate tests to avoid that kind of thing happening.
In theory if we have a small json index identifying the versions of we've downloaded bower and then copied into core. If those same steps are re-run specifying the exact versions to use from the indexes then the downloaded files should be the exact same each time.
In that case it should be possible to make it so that if Jenkins sees that a resources/*/ folder that only contains 3rd party libraries is modified it will try executing a download/build itself and then compare the resulting files to the ones committed. This will tell it whether the files have been updated normally (since the index will point to the new version which the new files match) or the commit modifies 3rd party libraries locally. Then Jenkins can -1 the commit. Requiring that any 3rd party library is either left completely unmodified. Or moved to a separated directory if forked.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]