I wasn't aware that it's somehow possible to be able to automatically include the wikifont git submodule via test configuration. A similar task (T134683) was created about this in the past, which ended up being declined.

The normal way to define dependencies is composer.json or something in the zuul config files. I did not know if possible at all, but when it cannot be fixed, than the tests could never run on Refreshed. Than it should "softly" depend and check at runtime if the files are there and add it to the necessary config, but that could be complicated. Than the tests would run and not tests that part of the config.

Subscribed a few people which I believe interacted with mediawiki/skins/Refreshed at some point.

That is rather annoying, but the CI job does not process submodule at all. I can look into that though that would impact a lot of different Jenkins jobs and might have nasty side effects :(

A note: mediawiki/extensions/VisualEditor has a similar issue so it would benefit from having submodules to be processed. Some more skins and extensions might be in the same case as well. The root cause is T84942: Zuul-cloner should check out submodules the utility to clone repo intentionally does not process submodules because mediawiki/core wmf branches have hundreds of submodules :/

I don't know that much about either Composer or Zuul (only a little about the former), so I'll have to do more research today. :) If this is of interest to you, Refreshed skin's dependency is located at https://github.com/wikimedia/WikiFont.

Change 331012 had a related patch set uploaded (by Hashar):
Update submodule wikifont to canonical URL

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

Change 331012 merged by SamanthaNguyen:
Update submodule wikifont to canonical URL

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

Composer is a package manager for PHP. Lets one easily define a list of dependencies (in a file composer.json) that are then downloaded and installed automagically from https://packagist.org/ . So the idea would be to wrap WikiFonts in such a package so one can easily install it, then having to understand composer or git submodule is probably equally annoying for an unexperienced person.

Another solution would be to drop the submodule and embed a snapshot of WikiFonts directly in the Refreshed skin. The advantage is users just have to download the skin and it should work as is, it is a bit more tedious for the skin maintainers though, since you would have to periodically check whether there are updates, download, git add, git commit. But that is for sure easier for end users :-] MediaWiki core does that for the GUI library OOJS/UI which is directly embedded (that is required by the installer iirc).

From the other task:

In T134683#2612647, @Volker_E wrote:

I'm not quite sure if that's needed, I'd probably just include the font files in your skin and update it from version to version of your skin…

In T154806#2924619, @hashar wrote:

Composer is a package manager for PHP. Lets one easily define a list of dependencies (in a file composer.json) that are then downloaded and installed automagically from https://packagist.org/ . So the idea would be to wrap WikiFonts in such a package so one can easily install it, then having to understand composer or git submodule is probably equally annoying for an unexperienced person.

Another solution would be to drop the submodule and embed a snapshot of WikiFonts directly in the Refreshed skin. The advantage is users just have to download the skin and it should work as is, it is a bit more tedious for the skin maintainers though, since you would have to periodically check whether there are updates, download, git add, git commit. But that is for sure easier for end users :-] MediaWiki core does that for the GUI library OOJS/UI which is directly embedded (that is required by the installer iirc).

Thanks for the helpful explanation, it makes more sense now :) It shouldn't be too much of a problem I think to just embed a snapshot, since Wikimedia/WikiFont doesn't get updated too often. others: (@ashley @MtMNC @UltrasonicNXT @georgebarnick) Thoughts?

I have no strong feelings either way, but probably bundling WikiFont is the easiest option (not (just) from a CI standpoint, but also thinking of the average end-user who expects to be able to simply install the skin without having to perform additional dark magic).

What we could do is to build a new test that does git submodule init then git submodule update. The only problem is that if the module file is in a sub folder then we need to add support for defining a path for it to run.

OK, before we do anything, let's see how T154957 turns out (which I'm currently participating in). That ticket was created 4 hours after this ticket, and if the WikiFont project stops, it means work for it will stop and there won't be any more new icons. Do we still want to use WikiFont even if stopped? Do we want to switch back to something more actively developed such as FontAwesome?

(As a bonus, Dave Gandy, the creator of FontAwesome, made a KickStarter a while ago which succeeded with $1,076,960 raised. It was for helping to redesign the icons stuff and improve everything, which is at https://www.kickstarter.com/projects/232193852/font-awesome-5. There's obviously a ton of effort and work put into this iconfont project, and using FontAwesome would be most likely safe, secure, along with providing tons of icons to choose from!)

I'm currently somewhat split-ish, although I'm leaning towards keeping up WikiFont. I'll put most of my comments on the other task, and then we can see how to go forward with this task after that task reaches some sort of consensus.

In T154806#2924619, @hashar wrote:

MediaWiki core does that for the GUI library OOJS/UI which is directly embedded (that is required by the installer iirc).

Not by the installer, just by the tarball generation script (and it doesn't have to be like that). But we're getting off topic :)