Our current recommendation for adjusting PHPUnit configuration for
extension code coverage reports is to manually modify
tests/phpunit/suite.xml. This is cumbersome and annoying, since
suite.xml is version controlled.
This patch proposes a composer script to simplify editing
the (non-version controlled) phpunit.xml config in the root of the
MediaWiki repo. It is useful if you are interested in generating
code coverage reports based on unit tests only, not integration tests.
Usage: composer phpunit:coverage-edit -- extensions/GrowthExperiments
When you're done, you can run `rm phpunit.xml` to switch back to the
default phpunit.xml.dist.
The script will use the default includes/src/maintenance directories,
but a future improvement would be to identify the relevant directories
via the AutoloadClasses property of extension.json.
Another improvement would be to provide an option for passing
arbitrary paths in core, in case you are working on tests for a
specific class and want to generate coverage reports instantly.
We could probably also remove
dockerfiles/quibble-coverage/phpunit-suite-edit.py (which inspired
this patch) and use composer phpunit:coverage-edit instead.
Bug: T100294
Change-Id: Ia0ef41f67ca4a64b0d1ca0ddcee488c29630af0b
I benchmarked this again. The runtime of an unlimited explode() can be
quite high. This is not really a DoS attack vector as it would require to
post megabytes worth of input to the code, which will hit many other
limits before. I still consider it good practice to use unlimited explode()
only when it is actually allowed to return an unlimited amount of elements.
Change-Id: I30f8ca5dba7b317bb4a046b9740fd736b4eea291
The /vendor directory does not need to be web accessible, and to reduce
attack surface, it should not be web accessible. We can use the
post-install-cmd and post-update-cmd hooks to create a .htaccess after
the user has run "composer install" or "composer update". On the first
run of composer, this hook will be invoked twice due to the composer
merge plugin.
If the htaccess file already exists, this hook won't do anything.
Bug: T180237
Change-Id: I2cf6541750c90b5708d7cf5f81b914ae2d9d46d1
The old VersionConstraint class is deprecated in modern versions
of composer which use the version from the composer/semver library.
Bug: T119590
Change-Id: I52ad75e7e25f6583bb4b13489a09d2f2d934e67d
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
they support via Composer.
This change allows extensions to specify they depend on a specific
version or version range of MediaWiki. This is done by adding the
package mediawiki/mediawiki in their composer.json require section.
As MediaWiki itself is not a Composer package and is quite far away
from becoming one, a workaround was needed, which is provided by
this commit.
It works as follows. When "composer install" or "composer update"
is run, a Composer hook is invoked. This hook programmatically
indicates the root package provides MediaWiki, as it indeed does
when extensions are installed into MediaWiki. The package link
of type "provides" includes the MediaWiki version, which is read
from DefaultSettings.php.
This functionality has been tested and confirmed to work. One needs
a recent Composer version for it to have an effect. The upcoming
Composer alpha8 release will suffice. See
https://github.com/composer/composer/issues/2520
Tests are included. Composer independent tests will run always,
while the Composer specific ones are skipped when Composer is
not installed.
People that already have a composer.json file in their MediaWiki
root directory will need to make the same additions there as this
commit makes to composer-json.example. If this is not done, the
new behaviour will not work for them (though no existing behaviour
will break). The change to the json file has been made in such a
way to minimize the likelihood that any future modifications there
will be needed.
Thanks go to @beausimensen (Sculpin) and @seldaek (Composer) for
their support.
Change-Id: I8df66a92971146ab79cd4fcbd181e559115ca240