Gerrit 125050 introduced a banana checker as a linter to avoid lacking qqq messages in MediaWiki core and the installer in core.
Antoine commented: I would rather see a generic banana jenkins job template which we could apply on all repositories using i18n messages.
Version: wmf-deployment
Severity: enhancement
We need a grunt task and its dependencies added to the integration/jenkins.git repository which is cloned on all Jenkins slaves. Then it is all about:
Change 129826 had a related patch set uploaded by Jforrester:
[WIP] Generic banana linter job template
Why as a separate job template with its own working copy and grunt pipeline? I was going to phase out the wmfgrunt madness, not increase it, and instead promote local Grunt/npm-test more. Takes the same effort almost to set up (slightly less even I think), and makes it a lot easier to change in the future by not having to apply changes globally as that's physically impossible to upgrade once you put it out there like this.
Ah, never mind. I overreacted based on the code in this change:
https://gerrit.wikimedia.org/r/#/c/129826/2/macro.yaml
Made it look like a bin/banana-lint actually existed, which, if it would, would indeed be implemented that way. Please don't :)
@Antoine: Going with the route of calling our wmfgrunt copy from Jenkins into the context of the local repo is a very fragile approach that in addition causes various scalability and maintainability concerns that I'd very much not look forward to having to deal with.
Let's discuss this on IRC soon and see if we can come up with a better approach.
I would rather see a standalone job that we can run on any repository. I am not sure adding a npm file to all our repositories is a good idea.
What is wrong with having the 'banana' runner hosted integration/jenkins.git and a job per repository that just invokes bin/banana-lint ? If you want to let repositories finely tune the banana checker, maybe use a .bananarc?
(In reply to Antoine "hashar" Musso from comment #7)
Is that still being worked on?
Not really. Krinkle wants essentially to WONTFIX this bug and instead make each repo's maintainer learn and implement an npm pipeline instead with banana as one of the tasks…
(In reply to James Forrester from comment #8)
Krinkle wants essentially to WONTFIX this bug and instead make
each repo's maintainer learn and implement an npm pipeline
That makes really no sense to me. It's also not how I know Timo. Timo, is this what you meant?
(In reply to Siebrand Mazeland from comment #9)
(In reply to James Forrester from comment #8)
Krinkle wants essentially to WONTFIX this bug and instead make
each repo's maintainer learn and implement an npm pipelineThat makes really no sense to me. It's also not how I know Timo. Timo, is
this what you meant?
It's more nuanced than that, but yes, the idea is to phase out use of any Jenkins globals because they are not scalable, maintainable or usable.
Can't change without affecting all existing repos. Thus any upgrade to the version of the software (e.g. banana, jshint, etc.), or changes to its configuration (e.g. making it gradually more strict, opting in to additional checks etc.) is basically impossible as you'd have to magically make sure all existing repos pass in the microsecond the change is deployed or masters will be failing and people will be upset (and rightfully so).
We're already running into this mess with jshint (all repos using the generic job are basically stuck at some random version, updating is a fragile gamble each time). At least jshintrc is local to the repository. But phpcs and banana aren't set up that way. Which reminds me, you can't really do a generic banana build right now because it doesn't have a generic way of specifying the configuration. We could build one if needed, though.
It makes sense to have conventions for which software to use and how to configure it, but installing it globally and running from Jenkins is a mistake and is imho naive to the fact how development actually works and has so far only incurred lots of overhead on the wrong side of the balance (me), when really it ought to be a distributed effort.
Users can't easily use it locally for there is no local install. And global installation affects other projects (e.g. anyone working on projects that do have a local install or, know you, you contribute to non-Wikimedia projects, you're fucked and have to dig through shits of conflicting versions in your global binaries). We've ran into this with jshint many times (e.g. I prefer JSHint 3 for most projects, but some still have JSHint v2 config files, which may be incompatible).
A local workflow means you can keep a simple "make install & test" -like workflow (be it "npm install && npm test", "travisci", "composer install/run-script test", "./scripts/ci", whatever). Which means there's no difference between local and Jenkins (no black box stuff that developers can't run locally before pushing commits for review, and always the same predictable results).
Each of these create loads and loads of more jobs for each project in jjb-config and zuul-config. All of which have to be created manually and kept up to date. Usually requested by new and existing repos to be enabled etc (thus more overhead for Antoine and myself). The local pipeline means people are in control of it and don't need us for each little thing. This allows them to do it faster themselves, and the change itself is also simpler (one commit changing a line in their package.json/Gruntfile vs. commit to jjb-config, compile, deploy to Jenkins, commit to zuul-config, and deploy via gallium, reload Zuul).
It also increased overall load on Jenkins with additional workspaces and copies. I think it's pretty obvious that going forward we should aim for one job per pipeline per repo (maybe with multiple variations thereof for different environments matrixes). Especially with the future sight of virtualising our builds in a sandboxed environment. There the overhead of separate jobs would be even higher (would be wasteful to use separate VMs for each of these mini scripts, that 1-2 second save probably isn't worth parallelising for, and besides, they aren't mutually exclusive; we can parallelise within a build as we'll be doing with phpunit for example).
Change 129826 abandoned by Jforrester:
[WIP] Generic banana linter job template
Reason:
Not going anywhere.
Yep. Projects should control what tasks they execute during a build. That makes for a faster and more scalable infrastructure (less duplication). And also ensures tests can easily be run locally by developers without depending on "Jenkins" state. It also makes for more maintainable iteration and upgrades as we can't force everyone to upgrade at once and break master.
Direction: Use composer or npm test entry points (documentation). For example, use grunt-banana-checker.