Use the canonical MW_INSTALL_PATH

[hexmode]

Enable local test runs more easily with containers.

[codecov-commenter]

Codecov Report

Merging #691 (69ddbc8) into master (598c269) will not change coverage. The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #691   +/-   ##
=========================================
  Coverage     36.00%   36.00%           
  Complexity     2044     2044           
=========================================
  Files            75       75           
  Lines          7213     7213           
=========================================
  Hits           2597     2597           
  Misses         4616     4616           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 598c269...69ddbc8. Read the comment docs.

[gesinn-it-gea]

@hexmode @JeroenDeDauw how about using a layered Docker approach instead of a Makefile. With "layered approach" I mean Docker images that are build like onion rings. A first layer is already in production: https://github.com/gesinn-it/docker-mediawiki. This builds on top of the official MediaWiki Docker and simply installs MW, Composer and other required pieces. Adding additional layers building on top of gesinn-it/docker-mediawiki is super simple like adding SMW.

This would:

• create reusable Docker images
• speed up CI
• speed up local tests
• avoid code duplication

The Makefile feels like the time before we started using reusable installer scripts for Travis. It is a massive maintenance effort due to code duplication. It increases build time before being ready to test.

@gesinn-it-wam please share your experience using a layered Docker approach here.

[gesinn-it-wam]

The Makefile does not build a docker image containing all the required parts but only uses the MediaWiki base image and builds the container on top of it for every run (saving previous work on its own). I think that a more 'docker-style' approach could save some lines and time in the Makefile: Based on the docker image already used in the github workflow, I currently test (and debug) extensions using Dockerfiles of the form

ARG MW_VERSION=1.35
ARG SMW_VERSION=dev-master
ARG MERMAID_VERSION=dev-master
ARG SRF_VERSION=dev-master

FROM gesinn/docker-mediawiki:$MW_VERSION

RUN COMPOSER=composer.local.json composer require --no-update mediawiki/semantic-media-wiki $SMW_VERSION && \
    echo 'enableSemantics( "localhost" );' >> LocalSettings.php && \
    COMPOSER=composer.local.json composer require --no-update mediawiki/mermaid $MERMAID_VERSION && \
    echo 'wfLoadExtension( "Mermaid" );' >> LocalSettings.php && \
    COMPOSER=composer.local.json composer require --no-update mediawiki/semantic-result-formats $SRF_VERSION && \
    echo 'wfLoadExtension( "SemanticResultFormats" );' >> LocalSettings.php && \
    composer update && \
    php maintenance/update.php --quick

RUN echo ';zend_extension=opcache.so' >> /usr/local/etc/php/conf.d/docker-php-ext-opcache.ini && \
    echo ";zend_extension=xdebug" > /usr/local/etc/php/conf.d/99-xdebug.ini

COPY . extensions/SemanticResultFormats

CMD ["bash", "-c", "php tests/phpunit/phpunit.php --testdox -c extensions/SemanticResultFormats"]

Put it to the root of the extension folder and run the tests by

docker build . --tag srf && docker run --rm srf

The advantage is that most layers of the resulting docker image are built only once; even the COPY command only has to be executed, if there are changes to the folder. There is space for improvements and variations, of course:

• Instead of COPYing the source to the container one could mount it as a volume passed to docker run
• Use docker-compose instead of docker run/ docker build
• Run specific tests by hand: docker run --rm -t srf php tests/phpunit/phpunit.php --testdox -c extensions/SemanticResultFormats extensions/SemanticResultFormats/tests/phpunit/Unit
• Bash into the container (docker run --rm -it srf bash) and run the tests there
• ...

Depending on the problem at hand, I use combinations of all the possibilities.

[JeroenDeDauw]

https://github.com/gesinn-it/docker-mediawiki

@gesinn-it-gea I recommend renaming that repo to make it very clear those are images aimed at dev/test, not production.

[JeroenDeDauw]

The makefile indeed looks like a maintenance liability.

https://github.com/ProfessionalWiki/ExternalContent/ has my currently preferred approach. Same test scripts used locally and on CI. Freedom to use own local docker setup. No docker image dependency on GH Actions, instead setup step caching, resulting in typical execution time of ~3 sec.

[hexmode]

I'm going to re-submit this with just the first commit. I will address the Makefile concerns in another PR.