[23:19:18] Reedy: ok, I think I've figured it out. [23:19:27] Trying it locally, I can reproduce the issue. [23:19:32] It's kind of obvious in retrospect. [23:20:48] 1) sylink vendor -> ../mediawiki-vendor, 2) rm composer.ock, 3) run the giant 'composer require --dev' command at https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-php74-docker/21720/console#console-section-4 which is loggged without --dev but does get --dev as per https://github.com/wikimedia/integration-quibble/blob/f0fc5567dd22f3d1729c3a95adc33113393ca886/quibble/commands.py#L437 this is important because it can [23:20:48] "move" the entry within the composer.json from/to require-dev 4) run maintenance/checkComposerLockUpToDate.php [23:29:59] ugh, I can't reproduce it now [23:30:43] I suspect it has something to do with core being without the change, that's after all to avoid a circular dep and why update.php is told on this repo's CI to skip composer checks [23:31:15] although it seems the failing check is only meant to check the lock file within the vendor directory so I guess that shouldn't be an issue. It might be because we add dev stuff at runtime, but I can't reproduce it [23:31:25] not consistently enough to debug it anyway [23:31:50] it doesn't help that composer's non-interactive behaviour is not reproducible with interactive shell: https://github.com/composer/composer/blob/776ff2ea51bfa83335b14fa9a85fab5fc7d35050/src/Composer/Command/RequireCommand.php#L304 [23:33:21] the implicit 'else' of not having interactive is not possible to reproduce by answering yes/no. [23:33:36] but removing -it from docker run command will suffice [23:34:45] if I first delete my composer.lock file, I indeed get locally: [23:34:46] wikimedia/minify: 2.4.0 installed, 2.3.0 required. [23:34:46] Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies [23:34:52] which seems reasonable, except CI isn't failing that way.