Semantic MediaWiki/contributing: Difference between revisions

Created page with "Semantic MediaWiki extensions have all largely adopted the Gesinn IT Docker-based approach to development. Once you've cloned a particular extension (e.g. SemanticResultFormats), then you want to execute a submodule update to pull in the build environment. <syntaxhighlight lang="bash"> # change to the src directory cd ~/src # clone a SMW extension that you want to work on git clone https://github.com/SemanticMediaWiki/SemanticResultFormats # make sure you've got the la..."
 
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
Semantic MediaWiki extensions have all largely adopted the Gesinn IT Docker-based approach to development.
This page is a parallel to [[MediaWiki/contributing|Developer cheat sheet for contributing to MediaWiki]], for SMW.
 
Refer to the project's own [https://www.semantic-mediawiki.org/wiki/Contributing_to_Semantic_MediaWiki Contributing to Semantic MediaWiki] for the big picture perspective.
 
== Developer Cheat sheet ==
Semantic MediaWiki extensions have all largely adopted the [https://github.com/gesinn-it-pub/docker-compose-ci Gesinn IT Docker-based continuous integration] approach to development. There are many good reasons for this, chief among them is that it allows you to setup a complete (integrated) environment along with all the code, dependencies, tooling and conventions for developing, debugging, testing and contributing enhancements. Case in point: dependencies. There are [[JavaScript]] dependencies defined in '''package.json''', [[PHP]] (and development) dependencies defined in '''composer.json''', and [[MediaWiki/Extensions|Extension]] dependencies defined in '''extension.json'''.


Once you've cloned a particular extension (e.g. SemanticResultFormats), then you want to execute a submodule update to pull in the build environment.
Once you've cloned a particular extension (e.g. SemanticResultFormats), then you want to execute a submodule update to pull in the build environment.
Line 14: Line 19:
# now we initialize the build system
# now we initialize the build system
git submodule update --init --remote
git submodule update --init --remote
</syntaxhighlight>
Then, also create a <code>.env</code> file in the project root to override the environment variables used by the build system
<syntaxhighlight lang="bash">
# .env file example
MW_VERSION=1.43
PHP_VERSION=8.1
DB_TYPE=mysql
SMW_VERSION=6.0.1
PF_VERSION=5.7 # compatible with MW 1.43
NODE_JS=true  # Enable Node.js for JavaScript tests
</syntaxhighlight>
You can also create a '''<code>docker-compose.override.yml</code>''' file in the 'build' directory. This example exposes a port on the host so we can view the web container at http://localhost:8080
<syntaxhighlight lang="yaml">
services:
  wiki:
    ports:
      - 8080:8080  # Use port 8080 for MediaWiki
</syntaxhighlight>
Error about docker not running?
<syntaxhighlight lang="bash">
# note that if you've been working with docker-desktop, you may need to reset your docker context to 'default' from 'desktop-linux'
# note that if you've been working with docker-desktop, you may need to reset your docker context to 'default' from 'desktop-linux'
docker context ls
docker context ls
docker context use default
docker context use default
</syntaxhighlight>
== Finally install the build system ==
<syntaxhighlight lang="bash">
# Install the build system
# Install the build system
make install
make install
# and check docker process status
docker ps
docker ps
# run some test
# run the Continuous Integration target of the makefile
make ci
make ci
</syntaxhighlight>
</syntaxhighlight>
More is covered at [[PHPUnit/using_PHPUnit]]
[[Category:SMW]]
[[Category:Semantic MediaWiki]]
[[Category:PHP]]