Add compose configuration for development environment

[nuest]

It would be interesting to have a specific compose configuration for plug-in development.

I've made a first attempt at this during the sprint in Heidelberg earlier this year, but did not get it to work fully: master...nuest:dev_image

So this issue is mostly to make sure others thinking along the same lines may profit from the first steps taken there. IMO the following bits are important:

• good instructions on how to run a plug-in from a specific directory on the host machine
• alternative instructions on running the whole OJS code (even old versions) from the host machine with a suitable (specific version) OJS
• debugging with editor on the host machine

Alternative things to try out:

• development environment within an additional container in the docker-compose configuration

[marcbria]

Sorry for the silence Daniel and thanks a lot for the initiative.

As far as "master" is now "main" the link is broken but you work is still reachable here:
pkp:main...nuest:dev_image

I feel like will need to move to multi-stage before we start a dev image, but you list of ideas is definitively a very good starting point.

Two additional tools that I think would be nice to add to this dev image (or stack) are:

• Trivy: a tool for testing docker container vulnerabilities.
  You can call this over any image as follows:
  $ trivy i pkpofficial/ojs:3_3_0-4
• SchemaSpy: generates an ER diagram of your database.
  You can add this to your docker-compose as follows:

  schemaspy:
    image: schemaspy/schemaspy:6.1.0
    volumes:
      - ./volumes/public/schemaspy:/output
    command: >
      java -jar schemaspy.jar
      -t mysql
      -host db
      -port 3306
      -db ${OJS_DB_NAME:-ojs}
      -u ${OJS_DB_USER:-ojs}
      -p ${OJS_DB_PASSWORD:-ojsPwd}
      -s ${OJS_DB_DATABASE:-ojs}
      -connprops useSSL\\=false
    networks:
      - private
    depends_on:
      - db

Keep talking about this in this thread.

[marcbria]

Additional tooling extracted from PKP dev team channel.

• essential stuff: git, composer, cypress, node (nvm), xmllint...
• xdebug: https://xdebug.org
• closure linter: which requires Java and an specific version of the linter.
• additional helpers scripts (backup&restore, easyPatch...)

About xdebug, to install it in a Dockerfile (over the php:7.4-apache) we only need two lines:

RUN yes | pecl install xdebug-2.8.1 \
	&& echo "zend_extension=$(find /usr/local/lib/php/extensions/ -name xdebug.so)" > /usr/local/etc/php/conf.d/xdebug.ini

Jonas details the client side configuration in the dev's channel as follows:

As ::1 will try to contact the image itself, I configured the router to assign a static IP to my machine and I've got such settings:

xdebug.remote_enable=on
xdebug.profiler_enable_trigger=on
xdebug.remote_host 192.168.0.100

There must be a better way to do it (without passing environment arguments), but I didn't mind about researching 🙂

Then in vscode I just added a setting to map the root folder in docker with my local working folder, this is my config (see the /var/www/html):

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "Listen for XDebug",
			"type": "php",
			"request": "launch",
			"port": 9000,
			"pathMappings": {
				"/var/www/html": "${workspaceRoot}"
			}
		},
		{
			"name": "Launch currently open script",
			"type": "php",
			"request": "launch",
			"program": "${file}",
			"cwd": "${fileDirname}",
			"port": 9000
		}
	]
}

[luisfelipe3d]

any update?

[marcbria]

Not sorrry Luís. We are overwhelmed and this is not a priority now.
But PRs are more than welcome... so feel free to create a docker-compose-dev.yml in the way you like.

Cheers,
m.