Provide documentation for configuring contrib projects to run similar checks locally

I developed https://github.com/ddev/ddev-drupal-contrib for this purpose. Folks are welcome to add it to various docs. It is looking like DDEV will become an official/default den env for drupal so this may be all we need.

The above is an amazing tool to use with "ddev", and that combined with the options explained here https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → provide good documentation and a decent starting point.

I'm not sure what this module can provide to make it easier. I'm not sure that trying to hook into a "composer.json" file for a module (which is not even mandatory) is out of scope for this project.

Having said that, I'm happy to be shown a new way to make things easier. If it can be added here great, and if it can't we can update the documentation and recommendations.

I'm not sure what this module can provide to make it easier. I'm not sure that trying to hook into a "composer.json" file for a module (which is not even mandatory) is out of scope for this project.

The reason I put this issue in this project was mainly because of my desire to mirror the results of the checks being run in the GitLab templates, but I thought that this would live in the drupal.org docs, not necessarily in this module.

This is an example of what I have been trying to do on a module I was working on recently. Maybe @moshe's approach is better, but my thought was that anyone could clone a module configured in a way similar to this, run composer update and then composer test to see the results.

    "require-dev": {
        "phpunit/phpunit": "^9",
        "drupal/coder": "^8.3",
        "rector/rector": "^0.17.1"
    },
    "scripts": {
        "phpcs": "vendor/bin/phpcs -p .",
        "phpcbf": "vendor/bin/phpcbf -p .",
        "rector": "vendor/bin/rector process --dry-run",
        "rector-fix": "vendor/bin/rector process",
        "phpunit": "XDEBUG_MODE=coverage vendor/bin/phpunit",
        "test": [
            "@phpcs",
            "@phpunit",
            "@rector"
        ]
    },

Having said that, I'm happy to be shown a new way to make things easier.

Same here!

The thing is that each module maintainer controls her composer.json and they are going to be too slow to add and maintain these script definitions. So i made a plugin to do that, and to assemble the codebase using same approach as Gitlab CI.

Of course other approaches are possible. I'm not sure what we specifically can do on this issue.

Given that we have no way of changing the "composer.json" file of a module and that there are two documented alternatives to run the tests locally in a very similar fashion to what GitLab CI does, I'm going to close this issue.

Having all modules adopting something like "composer test" would be a dream, and who knows, maybe this is the recommended way to run the tests in the future, but for now, I don't think there is anything that can be done within the contrib gitlab_templates.

Thanks for the conversation and the links/snippets all.

@moshe-weitzman - given the direction that "ddev" is taking, I'd say that it's totally ok to add your plugin to the documentation page https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

It's good to have two options to run things locally.

Many PHP libraries have composer commands that contributors can run for a quick sanity test of their contribution, which is a subset of what the full CI workflow may run on multiple environments/versions/etc., but still very useful to save time and CPU cycles.

So I like the idea of documenting somewhere on drupal.org what composer commands contrib modules could add (for purposes of a quick sanity test - it wouldn't be reproducing the entire CI environment(s) of course). This is especially useful for very part-time Drupal contributors who might not take the time to setup the recommended development environment, but could still save time by running these commands in whatever environment they do have. I haven't looked into this enough (yet) to write that documentation but maybe I'll try w/ one of my contrib modules..

So I like the idea of documenting somewhere on drupal.org what composer commands contrib modules could add (for purposes of a quick sanity test - it wouldn't be reproducing the entire CI environment(s) of course).

Agreed! Is there somewhere that we could at least point to and say "if you are interested in what dependencies GitLab CI installs to test your module, check out this section of this config file"?