https://bugzilla.wikimedia.org/show_bug.cgi?id=64045
--- Comment #10 from Krinkle <[email protected]> --- (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 pipeline > > That 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. ## Maintainable 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. ## Usable 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). ## Scalable 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). -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
