Hello,

I have tried Aegir since last week. First thank you for this platform. It is awesome.

When I try to verify platforms based on drush dl drupal (7 or 8) and install sites on its, it works.

But I wanted to test with a custom install profile (https://github.com/Drupal-FR/socle-drupalcampfr/tree/8.x-1.x/www), I have the following error when trying to verify the platform:

The command could not be executed successfully (returned: Changed permissions of [success] /var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php to 640 Generated config in write(): Drush configuration file [success] (/var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php) Changed permissions of [success] /var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php to 440 , code: 0)

Steps to reproduce:

  1. having Aegir installed
  2. outsite of Aegir, git clone https://github.com/Drupal-FR/socle-drupalcampfr.git
  3. cd www
  4. composer install
  5. copy the content of www into /var/aegir/platforms/socle-drupalcamp
  6. On the hostmaster, add a platform socle-drupalcamp

When I looked at the drush alias generated it seems that the alias is for a server and not a platform:

aegir@debian-x72j:~$ drush sa @platform_socledrupalcamp
$aliases["platform_socledrupalcamp"] = array (
  'context_type' => 'server',
  'server' => '@server_master',
  'remote_host' => 'localhost',
  'aegir_root' => '/var/aegir',
  'script_user' => 'aegir',
  'ip_addresses' => 
  array (
  ),
  'backup_path' => '/var/aegir/backups',
  'config_path' => '/var/aegir/config/platform_socledrupalcamp',
  'include_path' => '/var/aegir/config/includes',
  'clients_path' => '/var/aegir/clients',
  'master_url' => NULL,
  'admin_email' => 'admin@localhost',
);

When I tried to verify the platform with CLI, I hadn't any error.

aegir@debian-x72j:~$ drush @platform_socledrupalcamp provision-verify
Provision configuration root path /var/aegir/config exists.                                                                  [success]
Provision configuration root ownership of /var/aegir/config has been changed to aegir.                     [success]
Provision configuration root permissions of /var/aegir/config have been changed to 711.                  [success]
Provision configuration root path /var/aegir/config is writable.                                                           [success]
Provision configuration path /var/aegir/config/platform_socledrupalcamp exists.                              [success]
Provision configuration ownership of /var/aegir/config/platform_socledrupalcamp has been changed to aegir. [success]
Provision configuration permissions of /var/aegir/config/platform_socledrupalcamp have been changed to 711. [success]
Provision configuration path /var/aegir/config/platform_socledrupalcamp is writable.                       [success]
Provision client home path /var/aegir/clients exists.                                                                          [success]
Provision client home ownership of /var/aegir/clients has been changed to aegir.                             [success]
Provision client home permissions of /var/aegir/clients have been changed to 711.                          [success]
Provision client home path /var/aegir/clients is writable.                                                                   [success]
Changed permissions of /var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php to 640     [success]
Generated config in write(): Drush configuration file (/var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php) [success]
Changed permissions of /var/aegir/.drush/platform_socledrupalcamp.alias.drushrc.php to 440    [success]

Thanks for any help.

Comments

Grimreaper created an issue. See original summary.

helmo’s picture

For a platform alias the 'context_type' => 'server', is definitely not correct, but I don't see how that can happen.

I cloned the repo and could create a platform and site from it. The only extra step being that I ran 'scripts/init.sh' and 'scripts/update-scaffold.sh'

grimreaper’s picture

Hello,

Thank you very much for testing. I found out where the problem came from.

I download Drush in the project with composer and as for drush 8.x, Drush is able to detect if a local Drush is installed and use it (the Drush team added this feature to be able to have a Drush compatible with Drupal core per site in case of a global Drush no more compatible). So when verfiying the platform, Drush had changed and boom... no more Drush aliases, etc.

I removed my local Drush and then it worked (composer remove drush/drush), and then it worked, I have deployed a site with the standard profile.

The problem I have now is that my custom install profile is not detected. I tried moving it from profiles/custom to profiles and then verify the platform but it is also not detected.

PS: Yeah, I recently added scripts/init.sh, but scripts/update-scaffold.sh is run when using composer install.

grimreaper’s picture

Hello,

I found why my install profile was not detected.

It was because I did not have a .profile file and because it was in a subdirectory 'custom' profiles/custom instead of profiles directly.

As the .profile is not required,

I found the lines in provision/platform/provision_drupal.drush.inc for the directory scanned, in _provision_find_profiles():

if (drush_drupal_major_version() >= 8) {
    include_once('core/includes/install.inc');
    $profiles_subdirs[] = "./core/profiles";
    $profiles_subdirs[] = "./profiles";
  }

But I didn't find for the .profile file mandatory.

Do you think I can make a patch to add the following scanned directories?

./profiles/custom
./profiles/contrib

grimreaper’s picture

grimreaper’s picture

grimreaper’s picture

I saw that with commit http://cgit.drupalcode.org/provision/commit/?id=2840bc4af90d63057379bcac... .profile is no more required for D8. Thanks.

helmo’s picture

@Grimreaper can I assume that this is solved then?

grimreaper’s picture

Status: Active » Fixed

Hello @helmo,

Yes this can be considered as fixed. The question "Do you think I can make a patch to add the following scanned directories?" has its own issue #2650290: Cannot find profiles beneath top-level directories

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.