4

I would like to create a PR against Drush, so one of the core commands has additional options. But I'm not really sure, how should I setup my development environment, so I'm not losing my time moving code between my site-specific Drush and master branch I checked out elsewhere.

I see that Drush contains docker compose file (https://github.com/drush-ops/drush/blob/master/docker-compose.yml), but the wodby/php image apparently doesn't contain Drupal Core. I wasn't able to find any tutorial about this.

  • 2
    This may help: github.com/drush-ops/drush/blob/master/tests/README.md But yes, it does seem confusing and not explained in drush contributing.md. – mradcliffe Nov 21 '18 at 15:55
  • @mradcliffe Thanks, I know that. I just need a running Drupal site to test my changes. Running test after every change would be very inefficient. – Miloš Kroulík Nov 21 '18 at 16:36
  • @MilošKroulík Did you get anywhere with this? – Stefanos Petrakis Nov 30 '18 at 22:08
  • @StefanosPetrakis I'm sorry, I had other things to do, I will check those tips out and let you know. – Miloš Kroulík Dec 2 '18 at 16:53
6

a) Start by reading the following material (if you haven't already):

b) Fork the drush-ops/drush repository, so that you can track your work (and eventually start a PR from your fork back to the original repo).

c) Install the local dev environment provided using docker-compose:

git clone https://github.com/stefanospetrakis/drush.git
cd drush
git checkout -b YOUR_BRANCH
docker-compose up -d
docker-compose exec drupal composer install

At this point you have the source code of drush, equiped with tests. You can do your changes and additions to it and commit/push to your fork, as your project evolves.

d) You can test your changes at any time, against the official drush test suite to make sure you didn't break something:

docker-compose exec drupal composer test

e) Additionally, you can test your work in progress inside your own drupal projects, by replacing the standard drush in composer with your own fork, that would need three things:

  • Adding an extra repository in your Drupal's composer.json, e.g.:

    "type": "git",
    "url": "https://github.com/stefanospetrakis/drush"
    
  • Aliasing the "drush/drush" package, in order to pull from your current working branch in your repo, based on the exact version number found in composer.lock, e.g.:

    require "drush/drush": "dev-YOUR_BRANCH as 9.5.2",
    
  • Use source (git) for your drush package, e.g.

    {
    "config": {
        "preferred-install": {
            "drush/drush": "source",            
            "*": "dist"
        }
    }
    

    }

  • Possibly do manual pulls inside the vendor/drush/drush folder in order to get your latest work.

And as @greg_1_anderson mentioned in a separate answer, you will find Drupal Core under the sut directory of drush's source code.

Good luck!

P.S.: Replace https://github.com/stefanospetrakis/drush.git with the URL of your fork of drush-ops/drush repository, this is just an example.

  • Why are you suggesting git clone https://github.com/stefanospetrakis/drush.git, instead of official repo? – Miloš Kroulík Dec 20 '18 at 19:25
  • This is just an example, that should be your forked repository of drush-ops/drush, from which you can issue Pull Requests back to the drush-ops/drush repository. – Stefanos Petrakis Dec 20 '18 at 20:14
4

The Drush test suite on the master branch makes its own Drupal 8 site install for you. Drush calls this site the System Under Test, or "SUT".

Copy tests/phpunit.xml.dist to tests/phpunit.xml and enter your database credentials there.

The SUT will be created when you run the tests via composer functional.

You may use the SUT in ad-hoc testing by using the provided aliases, e.g.:

./drush @sut.dev status

UPDATE: phpunit.xml.dist has been moved back to its original location in the tests directory.

*IMPORTANT: The SUT is automatically destroyed at the end of each test run. export UNISH_DIRTY=1 if you'd like Drush to keep it around for ad-hoc testing.

  • It seems that composer functional doesn't create a fully working @sut.dev installation in docker environment. That means I can't test commands like sql-sanitize. – Miloš Kroulík Dec 20 '18 at 22:08
  • Forgot to explain about UNISH_DIRTY. Updated the answer. Also, you can try drush @sut.dev si if you'd like to install the SUT without running the functional tests. – greg_1_anderson Dec 26 '18 at 5:46
1

What I would do to start with is to create my drupal 8 site using the drupal-project composer action, as recommended.

Part of that will cause drush to be installed under /vendor. Convert that into a full clone of the repo and make your changes there.

You should be able to test inplace to some degree, but if you want to test the new drush code on your main site, make a softlink from vendor/drush to the new site's vendor/drush. These days drush always prefers to use the installation within a site folder.

Hope that helps.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.