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: https://github.com/pkp/docker-ojs/compare/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: https://github.com/pkp/docker-ojs/compare/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 :slightly_smiling_face:

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.