Babel: it-N, en-3, fr-1, de-1
This might be a bogus error. Cannot modify header information - headers already sent happens when header() (or a similar function) is called, but some content was already sent. This can happen for lots of different reasons, but usually it is due to a previous PHP warning/notice. Less common is intentional output (e.g. echo), or whitespace before a <?php tag. The error message also says:
Fri, Apr 16
Thu, Apr 15
@Legoktm I've just tried packaging php and taint-check separately. It should be doable if we:
Thinking about this again, I think it would make more sense to install pcov in the base PHPXY images, since xdebug is installed there, and it'd be easier to reuse. My next question is: is there a specific reason for not using sury-php in the PHP 7.2 image? Being able to install pcov there would possiblycould make it easier to run tests with coverage; for instance, for T279423 I'd have to hack the phpunit command so it doesn't generate coverage on PHP 7.2.
Wed, Apr 14
AFAICS, it can be installed either in the composer-package-phpXX images or the more base phpXX (which is where xdebug is also installed). Regardless of this, it cannot be installed for PHP 7.2 because it doesn't use sury-php, so this change would affect PHP >= 7.3. https://gerrit.wikimedia.org/g/integration/config/+/da9ffb4ef300862a1c4ba164d6f697b50091584f/jjb/misc.yaml#45 should be updated, too.
Still fails for MW core, see https://integration.wikimedia.org/ci/job/mwcore-phpunit-coverage-patch/28456/console. That job still uses xdebug, see T234020#6987347.
A quick preview of the improvement (for GrowthExperiments):
Should be resolved now.
Not sure if this is what you meant, but vendor/bin/phan -d . --long-progress-bar will work. It's not very user-friendly, but AFAIK LibUp should add a composer script shortcut (composer phan) the next time it pushes something.
Above is my stab at it, implementing the solution I outlined above.
Tue, Apr 13
We cannot proceed until 1.38, when we'll remove the old schema.
The task description says:
(Reopening since I missed the second bullet. That one is blocked on the subtask)
The first line of that file reads
Mon, Apr 12
Sun, Apr 11
Oh, I just realized why. It's not a zend extension. It should be loaded with just "extension". Local testing confirms, and on my local install, I've always had "extension" too, so I'm not sure how I couldn't get it right.
I think the actual issue is a few lines above:
Sat, Apr 10
Fri, Apr 9
While I agree that this bug is really serious (being able to communicate is possibly the most important thing in a community), I'd also like to point out that the underlying issue is not just "we're not showing notifications to logged out users on the mobile version". The real issue is: "The mobile version doesn't show any notification if Echo is not installed". That is, without Echo, even registered users won't get any notification on the mobile version.
Memo: I missed some usages. I guess these can be migrated later. I also haven't checked whether pcov should be installed in more images for those jobs to be migrated.
Hmm I spoke too soon. The filter is loaded client-side using the QueryAbuseFilters API module. This means that we should first allow global filters to be searched via this API module, which is also a broader change (which I think would be fine). The real problem is that this module queries the database directly (as opposed to using FilterLookup), so it's not immediate to make it work with global filters. In fact, I don't even know whether query modules are supposed to query foreign databases. It might be doable with some hacks, but I'd rather not hack something if it's not supposed to be done.
Thu, Apr 8
I managed to fix my issue with kcachegrind so I was able to load bigger cachegrind files. I also managed to profile a complete run on AbuseFilter, after removing vendor and a part of core from the parsing phase (so it only had 1500 files to parse), which gave a 6G cachegrind file. However, I believe that it's not possible to do better, unless and until code filtering is implemented in xdebug (https://bugs.xdebug.org/view.php?id=1670). That would hopefully create much smaller cachegrind files, and also clearer output.
Tue, Apr 6
Integration tests only might still run reasonabley quick
Mon, Apr 5
I think this goes well beyond the scope of PHPCS. Phan has similar functionality in VariableTrackerPlugin, but not this specific feature. https://github.com/phan/phan/issues/2092 asks for that, so I guess it's a matter of waiting for it to be implemented upstream.
FTR, this is still broken. Not sure if anybody noticed, given that the priority was lowered to normal. See r676890 for an example (5 mins ago).
I think this specific instance can be resolved with PHPCS. We'd only be looking for a variable named $maintClass in the global scope in a maintenance script, as long as there's nothing more, codesniffer would suffice.