On 2013-10-12 7:27 AM, Niklas Laxström wrote:
2013/10/12 Daniel Friesen
<daniel(a)nadir-seen-fire.com>om>:
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_l…
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
[1]
https://gerrit.wikimedia.org/r/#/c/82116/ 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/]