acquia / acsf-tools Goto Github PK

Command line tools for working with Acquia Cloud Site Factory

PHP 100.00%

acsf-tools's Introduction

ACSF Tools

This tool is community-supported. Acquia does not provide any direct support for this software or provide any warranty as to its stability.

Summary:

This project contains a set of drush scripts designed to ease administering an Acquia Cloud Site Factory multisite platform. While Drush provides many utilities to aid generally in Drupal administraton, multsite in general and ACSF in particular adds a lot of complexity when managing multiple sites that live in a shared codebase. These tools merge ACSF multisites concepts with the ease of Drush-based administration.

Install and Configuration:

Install

For simpler projects with a single developer or very small teams, you can just clone this repository in your users' drush directory (e.g., ~/.drush).

For larger teams, we recommend adding this project as a composer library, e.g. composer require acquia/acsf-tools. See Using Composer to manage Drupal site dependencies if you're new to Composer.

Configuration

Rename acsf_tools_config.default.yml as acsf_tools_config.yml and save it in the same directory. Replace the following values:

Site ID: This is the ID of your Factory. The easiest place to find this string is in the URL of your production factory. It is the subdomain immediately succeeding 'www' in the URL. E.g., for "www.demo.acquia-cc.com", the Site ID is 'demo'.
Rest API User: This is your Factory username, which is displayed in the header after logging into your Factory.
Rest API Key: This is your Factory REST API key. After logging into the Factory, click on your username, then the 'API key' tab.
Rest Factories: This is an array of the URLs for your Prod, Test, and Dev factories. This should include a leading 'https://' as the protocol, and should not include a trailing slash.
Subdomain pattern: An optional config, used when staging custom domains from production, that allows you to define a custom subdomain pattern. E.g., 'foo-dev.coolsites.com', where '{subdomain}-{env}' is the default.
Prod Web: The server ID for your main production server. This is found in your cloud.acquia.com dashboard, under the servers tab. E.g., 'web-1234'.
Dev Web: The server ID for your development server. This is found in your cloud.acquia.com dashboard, under the servers tab. E.g., 'web-1234'.

Note: The acsf_tools_config file is deliberately ignored via .gitignore. The idea is that most of these utility scripts should only be ran by a platform admin with the appropriate permissions on their local machines. You should not be committing API credentials to your repository.

Tools:

Generate Drush Aliases

acsf-tools-generate-aliases (sfa): This command will query the ACSF REST API and store a list of all of the sites in your factory locally. It will then move a dynamic alias template into your drush folder. The template will load the list of sites when the drush cache is cleared and make a prod/test/dev alias available for every site in your factory. After running this command the first time, you should check in the generated '*.aliases.drushrc.php' (where * is your ACSF site ID) file to your repository. You will not need to check in anything else into your repo ever again, and can refresh the site list locally anytime you create/deploy a new site in ACSF.

Get Deployed Tag

acsf-tools-get-deployed-tag (sft): This command will fetch and display the currently deployed Git tag for the sites within a factory. E.g., drush @coolsites.local sft dev will display the currently deployed tag in the development environment.

Backup Sites

acsf-tools-sites-backup (sfb): This command will create a backup for a site or list of sites in your Factory. It accepts either a single site id, a list of ids, or 'all' to backup all sites. E.g., drush @coolsites.local sfb dev all will create a backup of all sites in your dev factory. You can get a list of site IDs in your factory by running drush @coolsites.01live acsf-tools-list.

Content Staging Deploy

acsf-tools-content-staging-deploy (sfst): This command will begin a content staging deploy from your Production factory down to one of the lower environments, i.e., dev or test. You can stage either a single site, a list of sites, or all sites. This is conceptually the same process as dragging your database and files from Production to Dev/Test in Acquia Cloud Enterprise/Professional (ACE/ACP), only the multisite equivalent for ACSF.

NOTE/WARNING: Content staging deploys will overwrite the current state of all sites in the lower environment. For example, if you are staging the production sites to the development server, this is will overwrite the databases that are currently running on the dev server with the contents of the production databases. Also note, if you are only staging a defined list of sites, this will replace the currently deployed sites in that environment with the sites selected in this command. If the list of sites you're staging is different from the sites currently deployed in that environment, the sites not included in your staging deploy will essentially be deleted in that environment.

Custom Domains Staging

acsf-tools-stage-domains (sfdo): Factory sites are given a default URL based on the user-defined ID, e.g., 'foo.coolsites.acsitefactory.com' where the site ID is foo. In many business use cases, these default URLS are not desirable, and we need a custom domain, e.g., 'foosite.com'.

This command allows you to take the custom domains as defined in production, and stage them down to the testing or development environments to maintain consistency, i.e., 'dev.foosite.com' and 'test.foosite.com'. This command will automatically detect the appropriate URL pattern, either based on the default 'www/test/dev' pattern, or a pattern you define in acsf_tools_config.yml.

Note: This script will stage domains for all sites in your factory, but will only applied to the sites that are actually present in that environment.

ACSF Tools

Note: The commands in this section are run remotely on a factory by remote drush alias, and do not require REST API authentication. E.g., drush @coolsites.01dev sfl will list all the sites in the development factory for the 'coolsite' subscription. This is the one exception to the 'always run local' rule. These commands do require SSH access via drush, same as any other drush remote execution script.

acsf-tools-list (sfl): This command will list the details (e.g., name, url, aliases) for all sites in your factory.
acsf-tools-info (sfi): This command will list site specific information (e.g., ID, Name, DB Name, Domain) for all sites in your factory.
acsf-tools-ml (sfml): This command will run any drush command against all sites in your factory. E.g., drush @coolsites.01dev sfml st will run the drush status command against all sites in your factory and return the output. This is useful for disabling clearing cache, or disabling a single module for every site in your factory.
acsf-tools-dump (sfdu): This command will create database backups for all sites in your factory.
acsf-tools-restore (sfre): This command will restore database backups for all sites in your factory.
acsf-tools-analyze (sfa): This command will extract information about modules, themes, entities, views from sites on a factory. It works with non-ACSF multisite installations as well.

acsf-tools's People

Contributors

Stargazers

Watchers

acsf-tools's Issues

Investigate if new feature to reorder sites impact acsf-tools commands

ACSF recently introduced a UI to order the sites: https://docs.acquia.com/site-factory/workflow/deployments/set-order-site-updates/

We should check if it impacts acsf-tools and how/if we can respect this order.

drush acsf-tools-ml sqlq "select count(uid) from users;" command doesn't work

Hi Team,

We are trying to run the command drush acsf-tools-ml sqlq "select count(uid) from users;" at our end. But it is not working. Also no other select queries are working either.

  Too many arguments, expected arguments "command" "query", provided arguments "command" "query".


sql:query [--result-file [RESULT-FILE]] [--file FILE] [--extra EXTRA] [--db-prefix] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--database [DATABASE]] [--target [TARGET]] [--db-url DB-URL] [--xh-link XH-LINK] [--druplicon] [--notify] [--] <command> [<query>]

I have checked the drush sqlq "select count(uid) from users;" --uri=example.com, it works fine.

Could you please have a look and let us know what might be the issue.

acsf-tools-ml does not run on custom domain

The drush acsf-tools-ml command get the list of sites from _drush_acsf_tools_get_sites() which itself get the info from the sites.json file. ml command then get the first domain and use it as uri parameter.
However, there is no guarantee the picked domain is the custom domain used on frontend (actually it is even guaranteed first domain is *.acsitefactory.com).

This has some impact on processes which rely on the given uri to build some url.

On our project, the image sitemap is listing *.acsitefactory.com/ urls because of that.

From the sites.json, there is no way to know the custom domain to use.

Do not require full bootstrap on acsf-tools:content-staging-deploy command

On 10.x-dev, the command is defined as:

  /**
   * A command line utility for starting a Factory content staging deploy.
   *
   * @command acsf-tools:content-staging-deploy
   *
   * @bootstrap full
   * @param $env
   *   The target environment you are staging content to.
   * @param $sites
   *   A comma-delimited list of site aliases you wish to stage. Pass 'all' to stage all sites.
   * @usage Single site
   *   drush @mysite.local acsf-content-staging-deploy dev sitename
   * @usage Multiple sites
   *   drush @mysite.local acsf-content-staging-deploy dev sitename1,sitename2
   * @usage All sites
   *   drush @mysite.local acsf-content-staging-deploy dev all
   *
   * @aliases sfst,acsf-tools-content-staging-deploy
   */

Is there a particular reason this command is being defined as @boostrap full ? AFAICT the code doesn't really need it, and this prevents running this command in CI scripts or in any scenario where there isn't a DB local connection available.

Install instructions seem to indicate it's ok to clone repo into ~/.drush but this doesn't work

I've been using a really old acsf_tools.drush.inc that I think I got many moons ago from Lindsey Catlett. The file was in my ~/.drush folder and seemed to be compatible with both Drush8 and Drush9.

I saw someone share an acsf-tools command that I didn't have, so decided to upgrade acsf-tools and found this repo. Using the older branch of 8.x-dev, I followed the install instructions which state:

For simpler projects with a single developer or very small teams, you can just clone this repository in your users' drush directory (e.g., ~/.drush).

However, this doesn't appear to be true, or if true it seems to require at least Drush 9, which is oddly not a dependency or a requirement, nor is there any warning.

When running drush8 with this repo installed in my ~/.drush directory, I get the following error:

Drush command terminated abnormally due to an unrecoverable error.                                                                 [error]
Error: require(): Failed opening required ''
(include_path='/Users/brian.tully/.composer/vendor/phing/phing/classes:.:/usr/local/Cellar/[email protected]/7.4.16/share/[email protected]/pear') in
/Users/brian.tully/.drush/acsf-tools/acsf_tools.aliases.drushrc.php, line 4

The line in question is:

// Load Composer to get to Symfony components.
$loader = require realpath(__DIR__ . '/../../vendor/autoload.php');

Which seems to indicate a composer requirement that is only supported in Drush 9 since it pulls in Symfony, etc.

Maybe we should update the install instructions to indicate that this is only supported by Drush 9+ ?

Add a limit option to acsf-tools-mlc

Using acsf-tools-mlc, it is easy to break your environment by running an expensive command on all the sites of the factory (drush acsf-tools-mlc cr for example).
We should add a --limit option to limit the number of sites to run in parallel.

Support using https urls in uri

When creating sitemap or caching image / file urls Drupal uses the URI parameter to build the absolute url. We should be able to specify if we want to use non-https or https url.

For instance

if I use drush -l https://nikunj.dev cron, in sitemap it will index urls with HTTPS
if I do drush -l nikunj.dev, in sitemap it will index urls with HTTP

By default with acsf-tools-ml only the domain is set in URI option without http or https.

ACSF-Tools doesn't work from ~/.drush global drush folder...

None of this is possible in global drush installation. When you composer install the dependencies, it is still missing the G folder from the docroot. It needs this for the gardens_site_data_load_file() function. The instructions on the github readme are wrong here.

All the paths have to be updated or changed to run from your global drush folder, however things still don't work even after fixing most pathing issues.

move the vendor directory from the acsf-tools folder to the .drush folder.
Edit line 4 of the acsf_tools.aliases.drushrc.php file
replacing '/../../vendor/autoload.php' with '/../vendor/autoload.php' basically changing the vendor path so its not in my personal users directory.
edit acsf_tools_generate_aliases.drush.inc removing one up path /../ from the line 57
$new_file = $realpath . '/../site-aliases/' . $new_alias_filename;
create the site-aliases folder in the .drush folder
edit your acsf_tools_config.yml
run the drush sfa command

No results come from the live site.

Release tag for Drush 10

Hello,

Please create tag for drush 10

'root_domain' key missing on `acsf_tools_config.default.yml`

On the 10.x-dev branch, the acsf_tools_config.default.yml file doesn't contain a root_domain key.
However, the code in \Drush\Commands\acsf_tools\AcsfToolsUtils::getRestConfig() is assuming it's present:

    $config = new \stdClass();
    $config->site_id = $yaml['site_id'];
    $config->username = $yaml['rest_api_user'];
    $config->password = $yaml['rest_api_key'];
    $config->prod_uri = $yaml['rest_factories']['prod'];
    $config->test_uri = $yaml['rest_factories']['test'];
    $config->dev_uri = $yaml['rest_factories']['dev'];
    $config->root_domain = $yaml['root_domain'];
    $config->subdomain_pattern = $yaml['subdomain_pattern'];
    $config->prod_web = $yaml['prod_web'];
    $config->dev_web = $yaml['dev_web'];
    $config->email_logs_from = $yaml['email_logs_from'];
    $config->email_logs_to = $yaml['email_logs_to'];

I'll submit a PR just adding that empty key to the scaffold file, but I'll probably not be able to expand the documentation to include it, since I'm not familiar to what this is used for.

Undefined array key error in AcsfToolsBackgroundTasksCommands.php

Steps to reproduce:

On a project with D9 + Drush10, pull the most recent 10.x acsf-tools code
Execute any drush command (locally)

Error is printed out:

 [warning] Undefined array key "AH_SITE_GROUP" AcsfToolsBackgroundTasksCommands.php:27
 [warning] Undefined array key "AH_SITE_ENVIRONMENT" AcsfToolsBackgroundTasksCommands.php:31

acsf-tools-ml with a command that has options passed does not work

I'm trying to run this:

acsf-tools-ml pm:list --type=module --status=enabled

But it's not handling the --type and --status options well.

I get an error The "--type" option does not exist.

I guess it's thinking --type is an option for the acsf-tools-ml command. Okay, so I tried this as well:

acsf-tools-ml -- 'pm:list --type=module --status=enabled'

But then I get error Command "pm:list --type=module --status=enabled" is not defined.

Use v2 endpoint for acsf-tools:content-staging-deploy

On the 10.x-dev branch, when executing drush acsf-tools:content-staging-deploy , we get a warning that the v1 endpoint is deprecated and the v2 endpoint should be used for this operation:

$ drush @default.dev acsf-tools:content-staging-deploy dev default
Staging deployment has been initiated - WIP6116. This endpoint is deprecated. Please use the v2 endpoint to utilize the single site staging feature.

When checking /api/v2/ on my factory environment I do see there is a single endpoint available:

GET /api/v2/stage
POST /api/v2/stage

I am not familiar with the changes, just wanted to surface this so we can track progress, when the moment is appropriate.

Support more than 100 site aliases

When generating a list of aliases the sfa command uses the REST API to fetch a list but will only get the first 100. We need 2000+.

Either support pagination or fetch directly from sites.json.

acsf-tools-ml profiles option does not handle case where profile can't be determined

One of my customer is having a "fake" site installed in his D8 factory which they simply use as a database container for a D7 site to be migrated in a new D8 site.
When running drush acsf-tools-ml status --profiles=my_profile, the command is executed on this D7 site.

I think the culprit is this line which does not handle the case where the site information are not present.

Update BLT-specific documentation

The 9.x README makes reference to some changes that have to be made for compatibility with BLT 9.1.0-alpha1.

BLT is about to roll these changes upstream, so all of this documentation can be removed after that happens. Just advise folks to use BLT 9.1.0 or later. acquia/blt#2911

Drush 10: ACSF-tools commands not working

Hi,

ACSF tools v10 dev branch has issues. ACSF tools commands are not working for me. I am using drush v10.3.5.

cset command not working with acsf-tools-ml
No drush messages with acsf-tools-ml command

Feature Request: Allow to skip the commands on sites which are under maintenance

Add a flag in commands like sfml and sfmlc to filter the sites under maintenance

Example: drush sfml status --maintenance-check

Example purposes:

We want to sync data from external system for only the sites which are live
We want to generate sitemap for only the sites which are live

Support ACSF stacks

This tool currently assumes a single webserver and sitename. This is not the case for all customers.

Command `acsf-tools:ml` permits operations on unavailable sites

Problem:
Executing drush @alias acsf-tools:ml command will execute the passed in command against all sites returned from gardens_site_data_load_file(). Depending on the drush command being executed, this can be problematic if any of the sites returned from that function are in a state where they cannot properly handle the command that is passed in.

Proposed resolution:
For each site returned from gardens_site_data_load_file() there is a flags array which contains several indicators of a site's current status. To prevent the execution of drush commands against a site which is not fully available, there should be a check for the access_restricted and operation flags to determine if the availability of a site.

Drupal 9 support

The main readme point to install acsf-tools either at (a) ~/.drush/ or (b) at the project.
For (b) a change seems to be needed to be compatible with Drupal 9 dependencies.

The problem:

It seems like current versions of acsf-tools, i.e. 8.x-dev, 9.x-dev, and 10.x-dev, depend on symfony/yaml 3.x, e.g. https://github.com/acquia/acsf-tools/blob/10.x-dev/composer.json#L23
Drupal 9 core depends on symfony/yaml 4.x, e.g. https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/composer.json#L32

This naturally result on not being able to install acsf-tools on a Drupal 9 project.

The best case scenario is to support symfony/yaml in both 3.x and 4.x versions.

I see the use is minimal:

$ git grep Yaml
AcsfToolsUtils.php:use Symfony\Component\Yaml\Yaml;
AcsfToolsUtils.php:    $yaml = Yaml::parse(file_get_contents($path . '/acsf_tools_config.yml'));

Hence, supporting both should be OK.
There are no breaking changes between those versions, e.g. compare https://github.com/symfony/symfony/blob/3.4/src/Symfony/Component/Yaml/Yaml.php#L80 and https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Yaml/Yaml.php#L76

I will add a related PR against 9.x-dev, since I see that 10.x-dev is still not ready as per #115 (comment) to support both 3.x and 4.x, but that same change may be applied/cherry-picked to other branches too.

Provide a command to list the sites which match a command response

For example, I would like to execute drush acsf-tools-ml cget shield.settings enable on the factory and get a list of the sites for which the response is true (or the reverse and list the sites for which the response is different than true).

Getting warning "Undefined property: Drush\Commands\acsf_tools\AcsfToolsCommands::$aliasRecord AcsfToolsUtils.php:44"

Steps to re-produce -

Run the command drush acsf-tools-dump -v and notice the warning.

At line https://github.com/acquia/acsf-tools/blob/10.x-dev/AcsfToolsUtils.php#L44

acsf-tools version using - 10
Drupal - 9.4
PHP - 8

Issue looks like alias is not set (seems because https://github.com/acquia/acsf-tools/blob/10.x-dev/AcsfToolsCommands.php#L638
::aliasValidate() is not called for DB dump command)

This change seems introduced in #154

--profiles option does not work anymore

acsf-tools-ml command has a --profiles option to filter the sites to execute the command on. It seems to not work anymore.

To determine the profile, the system currently does the following:

$site_settings_filepath = 'sites/g/files/' . $details['name'] . '/settings.php';
  if (!empty($profiles) && file_exists($site_settings_filepath)) {
    $site_settings = @file_get_contents($site_settings_filepath);
    if (preg_match("/'install_profile'] = '([a-zA-Z_]*)'/", $site_settings, $matches)) {

On the factory I am currently testing the command, this file is only containing:

<?php

require('/var/www/html/<subscription>.<environment>/docroot/sites/g/settings.php');

so the profile detection is failing.

Audit of users

Maybe this fits here:

https://github.com/alex-moreno/ACSF

Happy to merge my work on that repo here if you think it makes sense @sdelbosc @msherron

How to execute out of a context of a site

I am looking to see if these tools can help me create drush aliases for a few ACSF instances I have access to. Ideally I am after something self contained, that does not need to bootstrap drupal in order to run.

Currently I do not know this is possible:

 12:10:06  ~/projects/govcms-acsf-tools   8.x-dev ✘ ✭  ⬡ v8.4.0 
$ drush --include=. help sfa
Fetch the drush aliases for all the sites in your factory.

Examples:
 drush acsf-tools-fetch-aliases            Fetch drush aliases for all the sites in your factory.

Aliases: sfa

 12:10:21  ~/projects/govcms-acsf-tools   8.x-dev ✘ ✭  ⬡ v8.4.0 
$ drush --include=. sfa
Command acsf-tools-generate-aliases needs a higher bootstrap level to run - you will need to invoke drush from a more functional  [error]
Drupal environment to run this command.
The drush command 'sfa' could not be executed.

Looking at the drush command, it is expected to bootstrap to DRUSH_BOOTSTRAP_DRUPAL_SITE. Why is this the case?

Also, are you expected to run Drupal 8 on the ACSF instance? What is the significance of the 8.x branch in this repo?

[acsf-tools-dump] Create dump directory if not available

For the acsf-tools-dump, we have an option to specify the dump directory and default is ~/drush-backups if not specified.

In order to take a dump in a directory other than default, we first need to create the directory (if not available)

I think acsf-tools-dump should create the directory in the command itself if not already available.

cc @sdelbosc

Too many arguments, expected arguments "command" "cmd" "args"

Running the below command gives an issue Too many arguments, expected arguments "command" "cmd" "args".

my terminal> drush @mysite.01live acsf-tools:ml cset system.performance cache.page.max_age 43200

  Too many arguments, expected arguments "command" "cmd" "args".


acsf-tools:ml [--profiles [PROFILES]] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--debug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--notify [NOTIFY]] [--druplicon] [--xh-link XH-LINK] [--] <command> <cmd> [<args>]

Seems like multiple arguments is not yet supported by acsf-tools.

Improve the --concurrency-limit option on acsf-tools-mlc

As of now the --concurrency-limit option is splitting the commands by chunks. However, it waits for all the processes in the chunk to complete before starting the next chunk. In case one site is slow to execute the command, it will delay then next processes for no reason.
We should uses the processes in a better way to be sure we always use the maximum number of processes specified by --concurrency-limit option.

Add an option for domain pattern to acsf-tools-ml command

It is probably an edge case but some of our customers have one front-office domain and one back-office domain.

my-site.com
backoffice-my-site.com

We are using acsf-tools-ml for our scheduled tasks. By default acsf-tools-ml uses the first custom domain defined for the site, if none, it will use the default *.acsitefactory.com domain.
However, some of our scheduled tasks are intended to be executed with the front-office domain (xmlsitemap, newsletter emailing) whereas some other are intended to be executed with the back-office domain (media expiration, ...).
Some modules (like xmlsitemap) provides a config to enforce the domain to be used, however, it is not the case for all the modules.

Suggestion is to add an option to acsf-tools-ml to provide the pattern of the custom domain to find and use. --domain-pattern=backoffice for example.
The process should fallback to the current behavior in case the pattern does not match any of the custom domains.

Interactive drush acsf-tools

When running a command across all sites in a factory that normally prompts additional input, e.g. drush @dev sfml cset core.entity_view_display.taxonomy_term.brands.default content.field_slug.third_party_settings --value={} --input-format="yaml", the default response is automatically chosen.

I'd like to open a feature request that allows a user to select a response given a prompt.

Git tag for drush 10

Hello,

Please provide tag for drush version 10.

Support Drush 10

Is there a plan to support Drush 10?
Several drush_* functions should be replaced by the OOP code.

Drush commands not working

Hello,

I am using acsf tools v10, drush 10, drupal 8.9 and blt v11. Project with acsf
I see commands likedrush @be.01test acsf-tools-ml "cset -y cdn.settings status 0" are throwing error with acsf tools v10 which was working fine with earlier version of tool.

Only works for dev, test and prod environments

I have a fourth environment in my ACSF subscription, called "PPROD" (used for Pre-Production). Some of the commands like acsf:tools-get-deployed-tag don't work.

Checking the code I see that it would be needed to refactor the acsf_tools_config.yml file to be able to define an undefined number of webservers (PPROD uses one different than dev/prod), mayne in a similar way to the rest_factories entries.

Also, the logic that parses the yaml file would need to be adapted, and from what I can see in AcsfToolsUtils.php a few functions have the environments hardcoded too.

Are there any plans to support this?

sfml - option to skip by site name or ID

The sfml command is extremely useful, but it would be better if there were an option to skip specified sites. I realize there's currently a way to skip by install profile, but that doesn't cover the majority of cases where we need to skip. It would be nice to extend this logic to a comma separated list of sites names/IDs like so:

drush @site.name sfml some-command --skip=site1,site2,site3

Provide a command to trigger a code switch (POST /api/v1/update)

Is there a reason we don't have a command to trigger an environment update (code switch), using the /api/v1/update endpoint?

I can work on a proposal for this, but wanted to have initial thoughts on why this hasn't come up yet.

Composer error in instructions

The instructions say to require "drupal/acsf-tools", but it should be "acquia/acsf-tools".

acsf-tools-restore --help is confusing

Very minor

$ drush acsf-tools-restore --help
Restore a DB dump for each site of the factory.

Examples:
 drush8 acsf-tools-restore                 Restore DB dumps for the sites of the factory. Default source folder will be used.                               
 drush8 acsf-tools-restore                 Restore DB dumps for the sites of the factory using files from the specified folder.                             
 --source_folder=/home/project/backup/201                                                                                                                   
 60617                                                                                                                                                      
 drush8 acsf-tools-restore                 Same as above but using compressed DB dumps.                                                                     
 --source_folder=/home/project/backup/201                                                                                                                   
 60617 --gzip                                                                                                                                               
 drush8 acsf-tools-restore                 Restore DB dumps forcefully without any prompt message needed for confirmation on all the sites of your factory. 
 --source_folder=/home/project/backup/201                                                                                                                   
 60617 --gzip --no-prompt

Options:
 --gzip                                    Indicate the dump have been compressed using gzip. See acsf-tools-dump options. 
 --source-folder                           The folder in which the dumps will be picked-up. Default to ~/drush-backups.

option is source-folder. However the examples show source_folder.

ACSF-Tools command continue for next site on failure

acsf-tools-ml command not having exception handling and thus not executes on all sites if fails/exception on one site.

Example -
We are running db-update using this command. There are still some old site which are no longer available on env and thus when this command runs on those, we get exception and thus commands terminates there.

In Process.php line 235:

  The command "/mnt/www/html/*/vendor/drush/drush/drush status  --uri=URIHERE --root=/mnt/www/html/*/docroot" failed.

  Exit Code: 1(General error)

  Working directory:

  Output:
  ================


  Error Output:
  ================

  In D8-settings.functions.inc line 137:

    Failed to connect to any database servers for database {*DBNAMEHERE*}.


  core:status [--project PROJECT] [--format [FORMAT]] [--fields FIELDS] [--field FIELD] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-d|--de
  bug] [-y|--yes] [--no] [--remote-host REMOTE-HOST] [--remote-user REMOTE-USER] [-r|--root ROOT] [-l|--uri URI] [--simulate] [--pipe] [-D|--define DEFINE] [--druplicon] [--notify] [--xh-link XH-LINK]
  [--] <command> [<filter>]

Warnings generated by the command

[warning] Undefined array key "AH_SITE_GROUP" AcsfToolsBackgroundTasksCommands.php:27
[warning] Undefined array key "AH_SITE_ENVIRONMENT" AcsfToolsBackgroundTasksCommands.php:31

Drush 9 Support

Drush 9 support should be added since BLT 9.1.0 is being released soon.

Add a --total-time-limit option to acsf-tools-ml command

Context
I need to process a queue across an ACSF instance with several (80+) sites. Ideally I would like a way to execute as many items as possible across sites on a given time limit so the servers aren't overwhelmed by queue processing for a very long time.

Propposed solution
Allow acsf-tools users to specify a --total-time-limit option in the acsf-tools-ml command. If this option is present, the given command will be executed multiple times within the given time limit.

acsf-tools-generate-aliases for version 9

Hi,

We find hard to easily auto generate aliases for Drupal websites of an Acquia Site Factory.

Is the command acsf-tools-generate-aliases planned for acsf-tools with Drupal 9 ?

Otherwise, do you know an easy way to generate these aliases ? The final goal being to run blt sync from a local development machine.

Cheers

mysql dump failing with PROCESS privilege permissions failure

See: drush-ops/drush#4489

> mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

Other projects seem to fix it in a similar way (just adding the flag): https://github.com/massgov/openmass/pull/646/files

Cloud IDE has solved it in a different way, granting permissions, but that may not be suitable for everyone as per security concerns: https://github.com/acquia/ads-remote-ide-proxy/pull/381/files

More information:

acsf-tools-restore seems blocked if --gzip is given but .sql file already exists

I have the following /dump directory

- site1.sql
- site2.sql.gz
- site2.sql
- site2.sql.gz

The *.sql files are results of manual testing.
When running the command

drush acsf-tools-restore --source-folder=/dump --gzip

The command seems blocked without any output. I suspect it is because the gunzip -k command prompt a question which is not displayed and not answered by drush.

Attempting full bootstrap while trying to run acsftoolsCommands.

Commands under AcsfToolsCommands.php don't require DRUPAL_BOOTSTRAP_FULL to execute. Site level bootstrapping is sufficient for all of these commands to function correctly & they were set to the same till 8.x. With 9.x, this seems to have changes to full bootstrap & is causing issues on ACSF while trying to execute these commands without --uri parameter.

Drupal 10 support.

acsf-tools has a dependency on "symfony/yaml": "^3.0 | ^4.0" but Drupal 10 depends on Symfony ^6. Are there any plans for a release for D10 and Drush 11+ for that matter?

Unable to run commands from Drush

I've installed via composer as suggested and the code has been placed in /drush/contrib/acsf-tools
However Drush can't seem to to see these new commands after a drush cc drush and a drush cr - is there an extra step to make them available?

I'm on BLT9, Drush Launcher 0.5.1 and Drush CLI 9.2.1.

acsf-tools-dump override existing dumps if exists

Due some recent change, acsf-tools-dump is automatically creating a folder yyyymmdd (20200722 for example) inside the given --result-folder (drush acsf-tools-dump --result-folder=/backup will store the dumps in backup/20200722).

As of now, running the command twice a day will generate a unique folder and hence the first dumps will be override by the second execution. The pattern should be yyyymmdd-hhmm so running the command twice in a day does not override the dumps.

Also, I am sure which recent change included it but I am not 100% convinced by this automatic flow. I am used for example to take databases dumps before a code release and I was using the tag name in the folder name (for example drush acsf-tools-dump --result-folder=/backup/pre_1.0.0 --gzip). With the new flow, this same command will store the dumps inside /backup/pre_1.0.0/20200722. The result-folder argument name is confusing because it is actually not the result folder anymore.

acquia / acsf-tools Goto Github PK

acsf-tools's Introduction

ACSF Tools

Summary:

Install and Configuration:

Install

Configuration

Tools:

Generate Drush Aliases

Get Deployed Tag

Backup Sites

Content Staging Deploy

Custom Domains Staging

ACSF Tools

acsf-tools's People

Contributors

Stargazers

Watchers

Forkers

acsf-tools's Issues

Steps to reproduce:

Recommend Projects

Recommend Topics

Recommend Org