jalama / drupdates Goto Github PK

Catch error when trying to commit updates

This is probably better handled by CI system but watching the Drupal security emails to trigger this script would be ideal for automation.

Allow for steps that happen after the environment is built.

• Drush commands
• system commands (like symlinking your /sites/default/files folder)

https://docs.python.org/2/howto/descriptor.html

Using something like the script below and a ~/.my.cnf file to make mysql updates easy create drush aliases on the fly.

ala, https://lastcallmedia.com/blog/drush-pro-tip-automatic-site-aliases

default is sendmail, need STMP to support Windows etc...

Allow sites to be rebuilt using make files. Will need to figure out how to rebuild make files.

Build a plugin that allows a dictionary of git repos to be passed from settings file or CLI option

Allow the deployment dates to be entered either on the CLI or in the settings file(s) for staging and Production deployments, they default to the following Friday.

Allow drupdates to add modules to repo(s) as an option passed via CLI

Ideally we can hand all handling of SQL databases to drush. One quirk is that drush --db-su doesn't work without a $HOME/.my.cnf file if you don't have a password on your MYSQL super user account (note: homebrew installs mysql with no password on root by defult) as detailed in this gist https://gist.github.com/jalama/bf3713481b1657f90f1c.

The mysql plugin should conditionally add the $HOME/.my.cnf only if the root password is empty and the driver is mysql. Further the site alias file (drupdates.aliases.drushrc.php) should conditionally add the super user and super user passwords to each site definition. Theoretically, this should give Drupdates support for any DB Drush supports. If this works the mysql driver would just become a more generic sql driver.

Build an install script that will poll the user for settings values when the script is installed

it's currently just glocal functions

Need to verify that the listed remote git repo is valid

Allow for multiple working directories. To that end allow for the each working dir to have its own settings.yaml file. This would allow you to have multiple configurations per working dir say you have different data stores, file structures, etc...

After refactoring the "deploys = pmTool.deployTicket(siteName, commitHash)" call in the updates.py file won't work as the commitHash variable is null

If a setting is not in the yaml settings file(s) return ""

Build in support for users overriding classes/plugins in local installs. Maybe by adding classes to ~/.dr updates folder

The sitebuild() fails silently with simple error messages. Need to add its error to the reports

Catch merge conflicts, report and continue

Use slack to notify user of site updates report

The script should support the download and update of 3rd party libraries, this may be supportable through drush "up".

Stored in the /bin folder create a bin script to run this from the CLI and be able to pass any setting (including lists and dictionaries) as options (ex --uname='jalama' --blacklist='www.facebook.com, www.google.com')

Example, allow reports controller to send report via both sendmail and SMTP plugins.

The following files/symlinks are placed in the file system and need to be removed

~/.drush/drupdates.aliases.drushrc.php
~/.drush/settings.py
~/.my.cnf

Allow the various arguments and options that drush up supports to be passed via CLI or as settings in YAML file(s)

Add the "requires" element to settings to indicate one setting depends on another one being set

Need to reset the _model property each time it is called, it's causing some settings to get the elements from other settings:
Ex. the webrootDir setting is showing the format = "list" when it should be "", this is from another setting that is a list, it is being carried forward by the _model property.

Allow the script to be run on a single site using a CLI argument or by setting it in the ~./drupdate/utils.yaml file

Allow for any given group of phases to be run:

• build sites
• update sites
• submit deploy tickets

Allows MYSQL (using ~/.my.cnf) to add/remove database in order to facilitate building sites.

@see http://dev.mysql.com/doc/refman/5.6/en/option-files.html

Email a report of the sites that have been updated. The recipients of the report can be set in the settings file(s) or via CLI. The information included should include that sites were updates, the specific modules updates (if any) the url of the various deployment tickets, etc...

allow for the following formats/extensions

• gz
• tar.gz
• zip
• tgz

When a setting is blank (ie MYSQL user name or Stash password) and it's needed prompt the user for the setting value.

Need a primitive plugin system for pm (i.e. AtTask, JIRA, etc…) and repo sites (ie Stash, GitHub, Gitorious)

This way --help formatting is not a complete mess