geerlingguy / ansible-role-drush

Ansible Role - Drush for Drupal

Ansible Role: Drush

Installs Drush, a command line shell and scripting interface for Drupal, on any Linux or UNIX system.

Requirements

PHP must be installed on the system prior to running this role (suggested role: geerlingguy.php).

Global composer installation requires Composer to also be installed on the system (suggested role: geerlingguy.composer).

Source installation additionally requires Git and Composer to also be installed on the system (suggested roles: geerlingguy.git and geerlingguy.composer).

Role Variables

Available variables are listed below, along with default values (see defaults/main.yml):

Drush Launcher

Drush Launcher is a small wrapper around Drush for your global $PATH.

It is the recommended way to use drush, but there are some situations where you might wish to install and run Drush globally without using Drush Launcher. The following variables control Drush Launcher's installation:

drush_launcher_install: true

Set to no if you don't want the launcher installed.

drush_launcher_version: "0.10.1"

The version of the Drush Launcher to install. This should exactly match an available Drush Launcher release.

drush_launcher_phar_url: https://github.com/drush-ops/drush-launcher/releases/download/{{ drush_launcher_version }}/drush.phar

The URL from which the Drush Launcher phar file will be downloaded.

drush_launcher_path: /usr/local/bin/drush

The path where drush will be installed and available to your system. Should be in your user's $PATH so you can run commands simply with drush instead of the full path.

Drush global install via Composer

Some people need to have the full power of drush available globally, and this role allows the global install of Drush via Composer. If using this option, make sure you have Composer installed!

drush_composer_global_install: false

Set to yes (and set drush_launcher_install to false) if you want to install drush globally using Composer.

drush_composer_version: "~11.0"

The version constraint for the global Drush installation.

drush_composer_update: false

Whether to run composer update drush/drush to ensure the version of Drush installed globally is the latest version.

drush_composer_global_bin_path: ~/.config/composer/vendor/bin
drush_composer_path: /usr/local/bin/drush

The global path where Composer installs global binaries, and the path in which you'd like the drush binary to be placed.

NOTE: Composer 'global' installation is global to the user under which Drush is installed—e.g. if you install globally using the root user, drush will only work properly as root or when using sudo.

Variables used for source install (Git).

You can also install Drush from source if you need a bleeding-edge release, or if you need a specific version which can't be installed via Composer.

drush_install_from_source: false

Set to yes (and set drush_launcher_install to false) if you want to install drush globally using the Drush source code.

drush_source_install_bin_path: /usr/local/bin/drush
drush_source_install_path: /usr/local/share/drush

The location of the entire drush installation (includes all the supporting files, as well as the drush executable file.

drush_source_install_version: "11.x"

The version of Drush to install (examples: "master" for the bleeding edge, "11.x", "10.x", "6.2.0"). This should be a string as it refers to a git branch, tag, or commit hash.

drush_keep_updated: false
drush_force_update: false

Whether to keep Drush up-to-date with the latest revision of the branch specified by drush_version, and whether to force the update (e.g. overwrite local modifications to the drush repository).

drush_force_composer_install: false

Use this if you get an error message when provisioning like Unable to load autoload.php. Run composer install to fetch dependencies and write this file. It will force a composer install inside the Drush directory.

drush_composer_cli_options: "--prefer-source --no-interaction"

These options are the safest for avoiding GitHub API rate limits when installing Drush, and can be very helpful when working on dependencies/installation, but builds can be sped up substantially by changing the first option to --prefer-dist.

drush_clone_depth: 1

Whether to clone the entire repo (by default), or specify the number of previous commits for a smaller and faster clone.

Dependencies

None.

Example Playbook

- hosts: servers
  roles:
    - geerlingguy.drush

After the playbook runs, the drush command will be accessible from normal system accounts.

License

MIT / BSD

Author Information

This role was created in 2014 by Jeff Geerling, author of Ansible for DevOps.

ansible-role-drush's Issues

Does not support Debian 8+

See geerlingguy/drupal-vm#1539 (comment)

cannot change to directory '/usr/local/share/drush': path does not exist

Just tried using this role but get this error every time (I'm even using your Composer role too).

TASK: [geerlingguy.drush | Install Drush dependencies with Composer.] ********* 
failed: [178.62.17.8] => {"failed": true, "rc": 258}
msg: cannot change to directory '/usr/local/share/drush': path does not exist

Switching between source and no-source fails.

Before 2.0 the default was to do a git clone & composer install.
This creates {{ drush_path }} as a symbolic link.
This fails if it already exists as a file.

The new default is to download a phar.
This creates {{ drush_path }} as a file with get_url.
This fails with a "src and dest are required for creating links" error if it alredy exists as a link.

So I see two issues:

• running 2.0 on a system provisioned with an older version will fail.
• switching between drush_install_from_source: yes and drush_install_from_source: no will fail.

Bug encountered with ansible 2.2.1.0

Slightly misleading info in README re: `drush_version` variable

Description

The permissible values for the drush_version variable vary according to the value of drush_install_from_source.

If (as in the default case) that value is set to no, the contents of drush_version are used to create the drush_phar_url variable.

However, the only mention of drush_version in the README comes under the heading Variables used for source install (Git) where it says

The version of Drush to install (examples: "master" for the bleeding edge, "7.x", "6.x", "6.2.0"). This should be a string as it refers to a git branch, tag, or commit hash.

But in the default case, drupal_version can only be a release, not a tag, branch, etc. This causes playbooks using values such as 8.x to fail since https://github.com/drush-ops/drush/releases/download/8.x/drush.phar does not exist.

Suggested resolution

1. Add drush_version to "Role Variables" section indicating only releases can be used.
2. Modify drush_version description in "Variables used for source install (Git)" section to explain that tags, branches, and commit hashes can also be used.

'Run drush to finish setting it up.' fails in some cases

I get this sometimes:

TASK [geerlingguy.drush : Run drush to finish setting it up.] ******************
fatal: [default]: FAILED! => {"changed": true, "cmd": ["/usr/local/bin/drush"], "delta": "0:00:00.052107", "end": "2017-02-25 16:35:35.078985", "failed": true, "rc": 1, "start": "2017-02-25 16:35:35.026878", "stderr": "Unable to load autoload.php. Run composer install to fetch dependencies and write this file (http://docs.drush.org/en/master/install-alternative/). Or if you prefer, use the drush.phar which already has dependencies included (http://docs.drush.org/en/master/install).", "stdout": "", "stdout_lines": [], "warnings": []}

In my case, it turns out that the install failed because of a missing tag in the Drush repo—the first clone failed, but mostly worked... then the second provision saw no changes in the 'clone the drush repo' task, and ended up not running the composer install, which precipitated this error message. I'm going to add a drush_force_composer_install variable you can use in that case.

Getting Internal Server Error for 2.0.1.tar.gz

When I try to download
https://github.com/geerlingguy/ansible-role-drush/archive/2.0.1.tar.gz
I'm getting a 500.

Is that a github issue or is there something to be fixed?

Install Console_Table via pear for Drush versions < 7

See: geerlingguy/drupal-vm#345

Basically old versions of Drush depend on Console_Table being preinstalled (since they don't use Composer). For some older projects, it's nice to be able to have Drush 5 or Drush 6... so it might be good to add a conditional to do this setup automatically if the drush_version | int < 7.

Need to look into what else would be required for support, and make sure that pear (Ansible has a pear module in 2.x, nice!) is available/working without jumping through too many hoops.

If it's too much work (e.g. adds 2+ more tasks), then I don't think I'll add the support.

Breaks when used with a phansible playbook

Hi,

I tried using this role in conjunction with a phansible.com generated playbook, but it breaks the provisioning process.

Breaks with this error:

TASK [geerlingguy.drush : Create drush symlink.] *******************************
fatal: [192.168.88.88]: FAILED! => {"changed": false, "failed": true, "gid": 0, "group": "root", "mode": "0755", "msg": "refusing to convert between file and link for /usr/local/bin/drush", "owner": "root", "path": "/usr/local/bin/drush", "size": 5033570, "state": "file", "uid": 0}

How to reproduce:

1. Create an ansible profile with phansible.com
2. Install this role through ansible-galaxy: ansible-galaxy install geerlingguy.drush
3. Add this role to the playbook.yml (- geerlingguy.drush)
4. Run vagrant up (and vagrant provision if necessary)

Cause and solution:

In main.yml I had to change the state parameter from 'link' to 'file':

- name: Create drush symlink.
  file:
    src: "{{ drush_install_path }}/drush"
    dest: "{{ drush_path }}"
    state: file

Appropriate solution for Drupal 8.4

Would value ability to install Drush 9 as required by Drupal 8.4 .... adopt Christopher Hopper's solution if appropriate?

Our production site is saying that we should update to Drupal 8.4.3 but we're finding all sorts of incompatibility issues with PHP version / Drush version / Drupal core version / contrib modules that seem to fall outside the control of Composer and need thorough investigation in our Drupal-vm systems.

I tried

    # Override Geoff's Drush install defaults
    # Install from source (git clone + composer-based install).
    drush_install_from_source: yes 
    drush_version: "master"
    drush_keep_updated: yes
    drush_force_update: yes
    drush_force_composer_install: yes

but I get Drush 8.1.15 instead of Drush 9 and of course, this doesn't account properly for drush global / site-local use of Drush 9.

Post install permissions issue

Hi Guy,

I have umask set to a very strict 077, and while this role sets permissions for drush itself correctly, it doesn't set it for the commands, so I end up with:

user@server:/var/www/mysite/webroot$ sudo ls -al /usr/share/drush/commands                                                      
total 32
drwx--x--x 8 root root 4096 Jul 30 13:51 .
drwx--x--x 8 root root 4096 Jul 30 13:51 ..
drwx--x--x 3 root root 4096 Jul 30 13:51 core
drwx--x--x 2 root root 4096 Jul 30 13:51 make
drwx--x--x 6 root root 4096 Jul 30 13:51 pm
drwx--x--x 2 root root 4096 Jul 30 13:51 runserver
drwx--x--x 2 root root 4096 Jul 30 13:51 sql
drwx--x--x 2 root root 4096 Jul 30 13:51 user

I'm guessing you're applying +x to these; it could do with +r as well.

Ensure Drush is installed globally via Composer never stops

I'm using this role but de task Ensure Drush is installed globally via Composer never stops.

site.yml

  roles:
    - role: geerlingguy.composer
      become: true
    - role: geerlingguy.drush
      become: true

vars.yml

drush_composer_global_install: true
drush_composer_update: false

Install directory confusion

Using the defaults:

   drush_install_path: /usr/local/share/drush
   drush_path: /usr/local/bin/drush

I am getting:

 Fatal error: require(): 
 Failed opening required '/var/www/drupalvm/vendor/bin/includes/preflight.inc' 
 (include_path='.:/usr/share/php') in /var/www/drupalvm/vendor/bin/drush.php on line 11

/usr/local/share/drush/includes/preflight.inc exists so why is drush looking in /var/www/drupalvm/vendor/bin/includes/?

Make Drush composer-based install CLI options configurable

Add a new drush_composer_cli_options variable in defaults, and allow it to be overridden so people can, for example, use --prefer-dist instead of --prefer-source for faster install.

Unable to update drush

Hey, I've already reported this issue in the drupal-vm repo (geerlingguy/drupal-vm#1594) but according to @thom8 it seems to be an ansible role issue.

Issue Type

Bug Report

Environment

Drupal-VM 4.7.0
Vagrant 1.9.6
VirtualBox 5.1.28 r117968 (Qt5.6.2)

OS

Microsoft Windows 10 Pro (Version 10.0.14393 Build 14393)

Full console output

config.yml

drush_version: "8.1.14"

vagrant reload --provision
[...]
TASK [geerlingguy.drush : Check current state.] ********************************
ok: [mydrupalvm]

TASK [geerlingguy.drush : Perform cleanup of old symlink.] *********************
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Install Drush.] **************************************
ok: [mydrupalvm]

TASK [geerlingguy.drush : Ensure Drush is executable.] *************************
ok: [mydrupalvm]

TASK [geerlingguy.drush : Clone Drush from GitHub.] ****************************
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Check for composer.json] *****************************
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Ensure Drush can be installed on Debian Wheezy.] *****
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Install Drush dependencies with Composer.] ***********
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Create drush symlink.] *******************************
skipping: [mydrupalvm]

TASK [geerlingguy.drush : Run drush to finish setting it up.] ******************
skipping: [mydrupalvm]

[...]

TASK [Configure host machine drush aliases.] ***********************************
changed: [mydrupalvm -> 127.0.0.1]

TASK [Ensure drush directory exists for vagrant user inside VM.] ***************
ok: [mydrupalvm]

TASK [Configure drush aliases for vagrant user inside VM.] *********************
changed: [mydrupalvm]

TASK [Ensure drush directory exists for root user inside VM.] ******************
ok: [mydrupalvm]

TASK [Configure drush aliases for root user inside VM.] ************************
ok: [mydrupalvm]

[...]
mydrupalvm       : ok=202  changed=2    unreachable=0    failed=0

vagrant@drupal:/var/www$ drush version
 Drush Version   :  8.1.10

Summary

Although if have set up the vm to use Drush 8.1.14 the current version is still 8.1.10. Of course I've updated my vm via vagrant reload --provision. I had to destroy the vm and install again to use 8.1.14.

Both options drush_keep_updated: yes and drush_force_update: yes don't resolve this.

It might related to Drupal-VM update 4.3.1 (2017-03-14), because of

• Removed now-unneccessary drush_keep_updated

Drush master doesn't install on Debian Wheezy (7)

Currently, when Drush dependencies are installed via composer install, the following error is thrown:

TASK: [geerlingguy.drush | Install Drush dependencies with Composer.] ********* 
failed: [127.0.0.1] => {"changed": true, "cmd": "/usr/local/bin/composer install --prefer-source --no-interaction", "delta": "0:00:01.506257", "end": "2015-06-23 18:37:15.540381", "rc": 2, "start": "2015-06-23 18:37:14.034124", "warnings": []}
stderr: Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for d11wtq/boris v1.0.10 -> satisfiable by d11wtq/boris[v1.0.10].
    - d11wtq/boris v1.0.10 requires ext-readline * -> the requested PHP extension readline is missing from your system.

FATAL: all hosts have already failed -- aborting

See upstream drush issue: drush-ops/drush#1409

And downstream issue: geerlingguy/raspberry-pi-dramble#48

Fails on "Install Drush dependencies with Composer." with drush5

I may be the only one who cares, but worth noting at least that the "Install Drush dependencies with Composer." step fails with Drush 5 (and presumably lower) since they do not include a composer.json file.

Install drush release version

After upgrading to ansible 2.2.0.0 for DrupalVM 4.0.0, installing drush with a release version instead of a branch cannot be provisioned again. This triggers ansible/ansible-modules-core#5504

I'm using the following options in DrupalVM

drush_version: "8.1.8"
drush_keep_updated: true
drush_force_update: true
drush_clone_depth: 0

Using defaults other than drush_version cause issues on initial provision.

drush_version: "8.1.8"
drush_keep_updated: true ( or no)
drush_force_update: no
drush_clone_depth: 1

'FAILED! => {"changed": false, "cmd": "/usr/bin/git checkout --force 8.1.8", "failed": true, "msg": "Failed to checkout 8.1.8", "rc": 1, "stderr": "error: pathspec '8.1.8' did not match any file(s) known to git.\n", "stdout": "", "stdout_lines": []}'

Is there a different combination of variables that should be used to install drush 8.1.8?

thanks

CI failing on composer idempotence bug in Ansible upstream

* [instance] => geerlingguy.drush : Ensure Drush is installed globally via Composer.

That task is failing currently due to this Ansible bug: ansible-collections/community.general#1179

For now I think I'll patch over it using command, with a note to switch back at some point... Waiting also to get this fixed in my Drupal role here: geerlingguy/ansible-role-drupal#85

Switch back to using composer module after Ansible 2.10.4 is released

Currently there's a bug in Ansible core that causes the composer module to not be idempotent with Composer 2+, so I switched in #51 to the command module. I'd like to switch back to the composer module though, so I set up this issue to track progress getting back to it.

Drush install for Drupal 8.4+ and Drush 9

Problem/Motivation

Drupal 8.4.x requires use of Drush 9. Drush 9 deprecates support for global installation methods using a drush.phar download or Composer global require. Further to this, Drush 9 will no longer support use of a .drush-use file and associated wrapper script, that points to a project Drush dependency.

Suggested Solution

The officially supported solution to running Drush from anywhere in a Project's path is the Drush Launcer command. It may be worth moving to that now.

1. Install the Drush Launcher (formerly webflo/drush-shim) instead of a drush.phar. This would prepare the Vagrant DrupalVM and other users of this ansible role for Drupal 8.4.x and Drush 9.

   diff --git a/defaults/main.yml b/defaults/main.yml
   index 704fb3f..7e8a25b 100644
   --- a/defaults/main.yml
   +++ b/defaults/main.yml
   @@ -1,7 +1,7 @@
    ---
    # Install from phar (faster, but less flexible).
   -drush_version: "8.1.10"
   -drush_phar_url: https://github.com/drush-ops/drush/releases/download/{{ drush_version }}/drush.phar
   +drush_launcher_version: "0.3.1"
   +drush_phar_url: https://github.com/drush-ops/drush-launcher/releases/download/{{ drush_launcher_version }}/drush.phar
    drush_path: /usr/local/bin/drush
   
    # Install from source (git clone + composer-based install).

2. Remove the option to install from source?

The Drush Launcher works with project installed versions of Drush 8, Drush 9, and future versions of Drush.

Related Links

• Drush: Docs » General » Install
• drush-ops/drush#2699 (comment)

Installation fails when upgrading Drush from 6.7 to 7.0.0

I tried to upgrade Drush from 6.7 to 7.0.0 using following options:

drush_version: 7.0.0
drush_keep_updated: yes

The problem is that since file /usr/local/share/drush/vendor/autoload.php exists, its creation was skipped and drush dependencies were'nt installed, so I got following error:

failed: [37.205.11.220] => {"changed": true, "cmd": ["/usr/local/bin/drush"], "delta": "0:00:00.093496", "end": "2015-08-30 22:11:01.244023", "rc": 255, "start": "2015-08-30 22:11:01.150527", "stdout_lines": [], "warnings": []}
stderr: PHP Fatal error:  Class 'Drush\Command\Commandfiles' not found in /usr/local/share/drush/includes/command.inc on line 1821
Drush command terminated abnormally due to an unrecoverable error.   [error]

Not a git repository error from "Clone Drush from GitHub" task.

I'm getting the following error when I try to use this role from within a packer push... build on Atlas.

I can't figure out why this is happening, and I'm not certain it's a bug with your role or not, but I thought I report it just in case.

Error : "refusing to convert from file to symlink for /usr/local/bin/drush"

Any advice on how to deal with this error?

TASK [geerlingguy.drush : Ensure globally-installed Drush is symlinked into bin dir.] ***
Monday 12 February 2024 10:55:27 -0500 (0:00:03.167) 0:02:10.091 *******
fatal: [10.x.x.x]: FAILED! => {"changed": false, "gid": 0, "group": "root", "mode": "0755", "msg": "refusing to convert from file to symlink for /usr/local/bin/drush", "owner": "root", "path": "/usr/local/bin/drush", "size": 310920, "state": "file", "uid": 0}
fatal: [10.x.x.x]: FAILED! => {"changed": false, "gid": 0, "group": "root", "mode": "0755", "msg": "refusing to convert from file to symlink for /usr/local/bin/drush", "owner": "root", "path": "/usr/local/bin/drush", "size": 310920, "state": "file", "uid": 0}

Remove dependencies on ansible-role-php ansible-role-git

This role works perfectly with stock ubuntu git and ondrej's php PPA. So it would be helpful if the hard dependencies on geerlingguy.php and geerlingguy.git could be made optional?

document conflict in variables

Document the fact that if drush_composer_global_install is set to 'yes', drush_launcher_install must be 'no', otherwise the role bails out with
FAILED! => {"changed": false, "gid": 0, "group": "root", "mode": "0755", "msg": "refusing to convert between file and link for /usr/local/bin/drush", "owner": "root", "path": "/usr/local/bin/drush", "size": 274420, "state": "file", "uid": 0}

Allow configuration of drush git clone 'force' parameter

See justification: geerlingguy/drupal-vm#239

Missing mysql client package causes Drush to fail

Hi,
I have just spend some time figuring out WTF when I got stuck on not being able to run drush commands when I finally realized drush requires mysql client to connect to DB and in case the DB is not local the package is not present.

Therefore I think the mysql-client package should be installed with Drush since it is basically a hard dependency.

Fix Ansible 2.4+ deprecation warnings for include

See title...

Git clone takes forever

This role frequently takes an inordinate amount of time to complete (as in, > 20 minutes). It seems often to be hanging on the git clone. Could we limit the clone depth or something to make it faster? Maybe we could add a "shallow_clone" config flag or something?

CI failing on Drush composer installation

It seems that the global install passes (or seems to), but when I try symlinking Drush into place, it can't find the original:

TASK [geerlingguy.drush : Ensure globally-installed Drush is symlinked into bin dir.] ***
fatal: [instance]: FAILED! => {"changed": false, "msg": "src file does not exist, use \"force=yes\" if you really want to create the link: /root/.composer/vendor/bin/drush", "path": "/usr/local/bin/drush", "src": "/root/.composer/vendor/bin/drush"}

So maybe Composer isn't installing global installs into /root/.composer/vendor/bin anymore as of Composer v2?