Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

Automatically generate drush aliases #140

Open
anotherjames opened this issue May 11, 2018 · 10 comments
Open

Automatically generate drush aliases #140

anotherjames opened this issue May 11, 2018 · 10 comments

Comments

@anotherjames
Copy link
Member

anotherjames commented May 11, 2018

Maybe each provisioned Drupal site could get a drush alias generated? This would be particularly useful for projects that you have ssh into parrot to be able to run drush commands. (e.g. those requiring versions of PHP that your host machine doesn't have - in my case, PHP 7.1.)

If this is a non-starter for some reason, I can accept that. Otherwise, if some pointers towards how to achieve it could be provided, pretty please, maybe I can make this happen?

@darthsteven
Copy link
Member

Yeah, should be fine!

Just need to write the alias files into the correct places.

Something like this manifest:
https://github.com/computerminds/puppet/blob/master/custom_modules/cm_serverbase/manifests/components/php/drush_alias.pp
and associated templates with the correct information in is probably the way to go.

@anotherjames
Copy link
Member Author

Thanks! Okay, well, for a start, let's figure out what the alias file needs to look like. I reckon something like this should suffice:

<?php

$aliases = array();
// @TODO For each directory within the parrot sites directory:
$basename = 'mysite.drupal'; // i.e. the current site's directory name.
$prefix = '/webroot'; // Only or sites that use a webroot sub-directory.
$aliases[$basename] = array(
  'uri' => 'https://' . $basename,
  'root' => '/vagrant_sites/' . $basename . $prefix,
  'php' => '/usr/bin/php7.1', // Unless .parrot-php7.0 or .parrot-php5 exist
  'local' => TRUE, // Required to avoid double-calling, see https://github.com/drush-ops/drush/issues/1870
);
// (endforeach)

I'm guessing ~/.drush/aliases.drushrc.php is a fine place to put this.

@anotherjames
Copy link
Member Author

(I realise that doesn't exactly match the per-site alias files templates in your link, but it's a start.)

@darthsteven
Copy link
Member

Put them in different files, then it'll be much easier to manage with Puppet.

@anotherjames
Copy link
Member Author

So... how would I translate https://github.com/computerminds/puppet/blob/master/custom_modules/cm_serverbase/manifests/components/php/drush_alias.pp into something for parrot? e.g.:

@darthsteven
Copy link
Member

What should define cm_serverbase::components::php::drush_alias ( be changed to?

Naming things is hard, but it should probably sit somewhere within parrot_drush

There are four file/@@file blocks, is the first one the only one we want?

You'll want one for each user that we use in Parrot, so probably the root and www-data accounts make sense. you can ignore the @file resources, as those are exported resources, which we won't be able to use in Parrot anyway.

Looking at https://github.com/computerminds/puppet/blob/2fe91f48af0743d5cf33a75c17e25eb29dc5da17/custom_modules/cm_serverbase/manifests/components/site.pp#L192 , I'm guessing that means we'd then want something similar in https://github.com/computerminds/parrot/blob/master/modules/http_stack/manifests/apache/site.pp ?

Yes.

I expect we then need the equivalent of https://github.com/computerminds/puppet/blob/master/custom_modules/cm_serverbase/templates/php/drush_alias.erb ... hmm, interesting that doesn't include the 'local' => TRUE bit....

Indeed we will. local => TRUE` is a recent Drush hack, right? Should our mainline CM Puppet include it do you think?

@anotherjames
Copy link
Member Author

Indeed we will. local => TRUE is a recent Drush hack, right? Should our mainline CM Puppet include it do you think?

Honestly, I don't really know! Other than me, the only other CM person to run into needing this was Ross, and I think he ended up solving his problem another way anyway, after trying various combinations of this flag.

@darthsteven
Copy link
Member

Presumably it wouldn't do any harm to have this in there?

@anotherjames
Copy link
Member Author

Well, it could do. These aliases inside parrot would be new, so there's nothing existing to break. Whereas aliases in our default puppet config already exist on servers, so unless we know they're broken, I'm concerned about changing them with something like this that really could change their operation.

@darthsteven
Copy link
Member

Okay, happy to leave until it appears to be a valid fix for something.

anotherjames added a commit that referenced this issue Aug 10, 2018
Fix owner & group of vagrant user’s alias file too.
anotherjames added a commit that referenced this issue Aug 10, 2018
Oops, totally hadn’t tested the previous commit.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants