Giter Site home page Giter Site logo

district09 / robo-digipolis-drupal8 Goto Github PK

View Code? Open in Web Editor NEW
1.0 10.0 0.0 235 KB

The Drupal8 task runner implementation. Extends robo-digipolis-helpers and implements the abstract functions to make the entire flow Drupal 8 specific.

License: MIT License

PHP 100.00%
robo robo-digipolis-drupal8 drupal8 robo-tasks web d09check22

robo-digipolis-drupal8's Introduction

Robo Digipolis Drupal8

Latest Stable Version Latest Unstable Version Total Downloads License

Build Status Maintainability Test Coverage PHP 7 ready

Used by digipolis, serving as an example.

This package contains a RoboFileBase class that can be used in your own RoboFile. All commands can be overwritten by overwriting the parent method.

Example

<?php

use DigipolisGent\Robo\Drupal8\RoboFileBase;

class RoboFile extends RoboFileBase
{
    use \Robo\Task\Base\loadTasks;

    /**
     * @inheritdoc
     */
    public function digipolisDeployDrupal8(
        array $arguments,
        $opts = [
            'app' => 'default',
            'site-name' => 'Drupal',
            'profile' => 'standard',
            'force-install' => false,
            'config-import' => false,
            'existing-config' => false,
            'worker' => null,
        ]
    ) {
        $collection = parent::digipolisDeployDrupal8($arguments, $opts);
        $collection->taskExec('/usr/bin/custom-post-release-script.sh');
        return $collection;
    }
}

Available commands

Following the example above, these commands will be available:

digipolis:backup-drupal8           Create a backup of files
(sites/default/files) and database.
digipolis:build-drupal8            Build a Drupal 8 site and package it.
digipolis:clean-dir                Partially clean directories.
digipolis:clear-op-cache           Command digipolis:database-backup.
digipolis:database-backup          Command digipolis:database-backup.
digipolis:database-restore         Command digipolis:database-restore.
digipolis:deploy-drupal8           Build a Drupal 8 site and push it to the
servers.
digipolis:download-backup-drupal8  Download a backup of files
(sites/default/files) and database.
digipolis:init-drupal8-remote      Install or update a drupal 8 remote site.
digipolis:install-drupal8          Install the D8 site in the current folder.
digipolis:package-project          Package a directory into an archive.
digipolis:push-package             Command digipolis:push-package.
digipolis:restore-backup-drupal8   Restore a backup of files
(sites/default/files) and database.
digipolis:sync-drupal8             Sync the database and files between two
Drupal 8 sites.
digipolis:update-drupal8           Executes D8 database updates of the D8 site
in the current folder.
digipolis:upload-backup-drupal8    Upload a backup of files
(sites/default/files) and database to a server.

Multisites / site aliases

Drupal 8 multisites are supported. There are two ways to implement them:

  1. Use Drupal's sites.php

This script can parse the site aliases from sites.php, where the keys of the $sites array are the urls and the values the folders (under the sites/ folder in the web root.

  1. Use properties.yml:

You can define you site aliases in properties.yml under the remote key in the same manner: keys are the urls, values the folders. For example:

remote:
  aliases:
    example.com: default
    alias1.example.com: alias1
    alias2.example.com: alias2

You can read more about the properties.yml file in the Readme of the helpers package.

Multisite settings files

If you want to symlink the settings files of each of your multisite installations (which is recommended, since the alternative would be to have them in your repository), you'll have to add those symlinks to the properties.yml. Same goes for the files directories.

Using the example above, you'll have to add this to your properties.yml:

remote:
  symlinks:
    # Settings file symlinks.
    - '${remote.configdir}/alias1/settings.php:${remote.webdir}/sites/alias1/settings.php'
    - '${remote.configdir}/alias2/settings.php:${remote.webdir}/sites/alias2/settings.php'
    # Files directories symlinks.
    - '${remote.filesdir}/alias1/public:${remote.webdir}/sites/alias1/files'
    - '${remote.filesdir}/alias2/public:${remote.webdir}/sites/alias2/files'

Rollbacks on multisites

Since backups are made at the beginning of the multisite deploy, every site of the multisite is rolled back whenever there is an error in the deploy process, even when the error happens during the deploy of the first alias. So in the example above, at the beginning of the deploy, a database backup is made for default, alias1 and alias2. If the process fails during the deploy of default, the rollback process will restore the database backups of default, alias1 and alias2. Some goes for when it fails during the deploy of alias2. Deploys are done in the order the aliases are defined.

Adding a new site to an existing setup

When a new site is added to an existing installation, make sure all settings files and folders are in place (just like you would with a normal first time installation). The site that was newly added will go through the installation process, the sites that already existed will be left alone. This means you can't update one subsite, while adding another at the same time. You'll have to do that in two separate deploys.

Installing from an existing database

This goes for both 'normal' and multisite installations. If for some reason you would like to create a new site starting from an existing (meaning non-emtpy) database (not recommended), you can. Just fill your database with the data you need and trigger the deploy. The deploy will detect there is no site yet (since there will be no code on your server) and trigger the install script. Once your code is uploaded to your server, the install script will be able to connect to the database. It will then detect there's allready data in it, and skip the install process. This way your code is uploaded to your server and it will use the existing database. If your database is behind on you code (meaning you'll need to trigger database updates), you'll have to execute a second deploy.

This is also the reason, that when adding a new site to your multisite installation, the existing ones will be left alone. We would have had to overwrite the entire base package (robo-digipolis-helpers) to detect which site of the multisite is a new one and which one is an existing one that might need an update. So instead, when the deploy script detects that at least one site of the multisite installation needs an install from scratch, the install script is triggered for all sites of the multisite installation. If then the install script runs for one of the existing sites, it'll detect the existing data in its database and leave it at that. For the newly added site there'll be no data (unless you manually entered it in the database) and it will trigger the installation for that specific site.

General gotchas

  • We assume the value of $config_directories['sync'] is relative to the web root. We prepend it with the path to the web root ourselves.
  • If multiple aliases point to the same folder, we only use the first alias in the array. Keep this in mind for e.g. your sitemap.

robo-digipolis-drupal8's People

Contributors

daften avatar jelle-s avatar matthijs-va avatar mpparsley avatar zero2one avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

robo-digipolis-drupal8's Issues

Clear Drupal cache before importing the configuration while upgrading an existing site

Problem

The configuration is imported during a site update.

It could be that a new plugin is defined in an existing module (already installed) and used in the config to import.

This will break the update as Drupal will complain it has to perform a config import of something it does not know.

Solution

Add a Drupal Cache rebuild step before running the config import step.

src/RoboFileBase.php:336

            $collection
                ->drush('cr');
            $collection
                ->drush('cim');

BLOCKER : Site install is no longer working

The site-install command is no longer working.

It looks like the Drupal site is not completely installed (only cache tables in the database).
Example : https://jenkins-web.gentgrp.gent.be/blue/organizations/jenkins/jobs_deploy_test/detail/jobs_deploy_test/4/pipeline/

Probably due to this line https://github.com/digipolisgent/robo-digipolis-drupal8/blame/develop/src/RoboFileBase.php#L170.
There is no vendor directory within the web dir, the proper path should be ../vendor/bin/drush.

Install broken due to wrong chmod() usage

Problem

php chmod() expects octal numbers (starting with 0), decimal values are used.
This results in strange behaviour (wrong chmod result).

Sollution

Prepand the chmod codes with a leading 0.
See http://php.net/manual/en/function.chmod.php

Note that mode is not automatically assumed to be an octal value, so to ensure the expected operation, you need to prefix mode with a zero (0). Strings such as "g+w" will not work properly.

Switch to drush for deployment flow?

Problem:
When faulty config is imported, every drupal console command fails, because the bootstrap that happens on each command fails. That means the restore at the end of the failed deploy fails as well.

  • First put an issue in drupal-console project if this can be fixed at a higher level.
  • Replace certain drupal console commands with drush commands to make sure the flow keeps working. E.g. the database restore.

The deploy task does not correctly detect empty database

Problem

The deployTask detects if there is an installed site by checking if the database is not empty.

When the sql-query returns empty lines, those lines are also counted as "tables" which result in an faulty detection and Site Update instead of install.

Solution

Update the isSiteInstalled method and filter out empty lines before counting the number of tables.

Drush error on initial install

When installing on a new (empty) server for the first time, drush throws an error during locale-check:

 cd /home/gfinvoer/apps/default/releases/1489587615/web && ../vendor/bin/drush locale-check && cd /home/gfinvoer/apps/default/releases/1489587615/web && ../vendor/bin/drush locale-update
PHP Fatal error:  Call to undefined function locale_translation_flush_projects() in /home/gfinvoer/apps/default/releases/1489587615/vendor/drush/drush/commands/core/locale.d8.drush.inc on line 53
Drush command terminated abnormally due to an unrecoverable error.       [error]

A drush cr before the check might fix it...

Drush 10 support

Drush 10 has been out for a while. I was wondering if it was gonna be supported?

Clean install gives error

When running ./vendor/bin/robo digipolis:install-drupal8 i get:
[error] Could not determine target sites directory for site to install. Use --sites-subdir to specify.

Is it possible that this is a new issue since Drupal 8.5.x?

Add the possibility to run drush deploy:hook

It's an interesting new way to run code very similar to update hooks, but after config import. See https://www.drush.org/latest/deploycommand/

This can be done fairly easily by adding an additional if block after the block for config-import. And also adding an additional opt 'deploy-hook'. This does require drush 10.3+, but if the default value is false, the responsibility can be put on the actual application using the package.

Check if there is a db prefix before passing it to the drush site-install command

Problem

The digipolisInstallDrupal8() method reads the settings.php file and uses the variables from $databases['default']['default'] to install the site. It passes always the prefixto the drush stack even if it is empty.

Since Drush 9.x.x a check is added when the db-prefix= argument is passed when calling site-install: if it is empty an error is thrown and the installation is aborted.

Solution

Check first if there is a prefix.

SHOW TABLES check not multisite compatible

The SHOW TABLES check as below isn't multisite compatible, it should be executed per site. Site A can be installed when B isn't.

[DigipolisGent\Deploy\Ssh] *@*:/*****/current/..$ [[ $({ vendor/bin/drush 'sql-query' 'SHOW TABLES' | grep 'users'; }) ]] || vendor/bin/robo --site-name='***' --config-import 'digipolis:install-drupal8' 'minimal'

Results in an error because we don't have a default site.

$webDir contains the path twice

ERROR: file_get_contents(/home/travis/build/digipolisgent/drupal8_site_stadgent/web//home/travis/build/digipolisgent/drupal8_site_stadgent/web/../config/sync/system.site.yml): failed to open stream: No such file or directory
in /home/travis/build/digipolisgent/drupal8_site_stadgent/vendor/digipolisgent/robo-digipolis-drupal8/src/RoboFileBase.php:556

Seems like the base path is added twice: /home/travis/build/digipolisgent/drupal8_site_stadgent/web/

install-drupal8 fails if generated password contains quotes (", `)

While running the install-drupal8 task, a password is generated for the drupal user 1 account.

The installation fails if that password contains quotes (", `).

Example where the generated password is ���Xr��`:x���G:

[Boedah\Drush\DrushStack] Running vendor/bin/drush site-install config_installer -y -r /Volumes/Webdev/www/digipolis/visitgent/visit-d8.gent.be/web --db-url='mysql://localuser:[email protected]:3306/digi_visit_gent_be_d8' --db-su=localuser --db-su-pw=localpass --db-prefix= --site-name='Drupal' --account-pass="���Xr��`:x���G"
sh: -c: line 0: unexpected EOF while looking for matching ``'
sh: -c: line 1: syntax error: unexpected end of file

Localised strings (translations) are not updated during deploy when using Drush 9 & Drupal 8.4.x

Problem

The update process checks, by getting a list of installed modules, if the locale module is installed.
This by performing a grep on the output of the drush pml command.

drush pml --core --fields=name --status=enabled --type=module --format=list

Output Drush 8:

Image (image)
List (list)
Locale (locale)
Menu (menu)
Node (node)

Output Drush 9 (This version has an extra field option display_name):

image
language
link
locale
menu_link_content
menu_ui
node
options

Solution

Add a helper function to get if a module is enabled (in DrushStack?). And build in the logic to support both Drush 8.x & 9.x.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.