First 2017 update: Composer, Integrations and more

First 2017 update: Composer, Integrations & more

The holiday season was a lot of fun for the Drop Guard team, but also very busy.  We've worked hard to deliver a whole package of impressive features and improvements to our update management platform. Big plans were also made for 2017. Without further hesitation let's start the New Year with the news!

Acquia Cloud & Pantheon integration

With the Acquia Cloud support available to all users, and the Pantheon support coming shortly, you can now take advantage of the Acquia Cloud and Pantheon API actions directly from Drop Guard. Want to set the cloud environment to a specific git branch or git tag? Create a backup of the database before the update? Perform a deployment? We've got you covered! Just establish the connection to your favourite platform and create the needed Action on the Events configuration screen.

Note, that not all the available API actions are supported at the moment, so please share the ones you would love to have in the comments to this post.

Slack connector

Slack integration allows being notified about available Drupal updates, update task errors, patches failures immediately on selected Slack channel. As with any other integration, create the connection to your Slack instance from the Integrations tab and add the appropriate Action. You can have multiple Actions posting messages to different Slack channels or users.

Taking Actions & Integrations for a test drive

Test command

Let's imagine you've created a Jira connection to maintain a 2-way integration between the update task created by Drop Guard and the automatically created Jira issue, so that once you change the issue status in Jira it gets auto changed in Drop Guard and vice versa. 

Previously the only way to check if the connection works was to 1. wait until the Drop Guard task is created, 2. check your Jira instance looking for the newly created task, 3. verify if the message posted with the task is what you expect and the status is correct. Once you've made some changes to your Jira configuration, the procedure had to be repeated. Sounds like a lot of work and wasting time waiting for new updates just to test drive your settings...

From now on this pain has gone. When establishing an integration, or creating any Action in Drop Guard, just look for the "Run a test command", "Send test message" or similar buttons of the respective connection, and you will be able to see the result of integration immediately in your connected platform or server.

Composer support improvements


Composer improvements

For several months, Drop Guard users were able to manage their Composer files with Drop Guard. The idea is simple - once the update is detected and the Drop Guard update task created, instead of committing the actual module or core codebase to the repository, Drop Guard now changes the project version in composer.json file to the next available one and updates composer.lock file accordingly.

However, some of our users weren't very happy of Drop Guard wiping their versions constraints set in composer.json file. So, for example, this line:

"drupal/admin_toolbar": "^1.17"

would be changed to this:

"drupal/admin_toolbar": "1.18"

To give users more control over the process, Drop Guard supports two Composer update modes now:

1. Ignore versions constraints (basic mode). In this mode, Drop Guard will update versions in both composer files replacing any specific constraints characters (tilde, caret, star) with the actual exact version of the module.

2. Respect versions constraints (advanced mode). Here Drop Guard will only manage your composer.lock file, respecting constraints set in composer.json. So if you, for example, do not want your module to be updated to the next major release, use this option and Drop Guard will fail the update task intentionally, allowing to take action manually.

Setting a location of Drupal code & composer files in the repository

In many cases Drupal core files are not located in the root of the repository, sitting in the "docroot", "www" or "web" directories instead. Same applies to composer files. 

Previously Drop Guard provided limited support for a non-standard location of Drupal core. Starting from now, you can specify the location of either the Drupal core or composer files anywhere in the repository.

Please note that you have to tell Drop Guard how to update your website first - in a traditional way or using Composer. It will affect the behaviour of the docroot location field, which is used for locating Drupal core OR Composer files.

See full trace of the error from the Drop Guard server

Failed task

We all make mistakes. It could be as simple as forgetting to remove the old patch, or as complex as Composer dependencies conflict. Unfortunately, Drop Guard is not (yet) smart enough as your average developer to be able to resolve human mistakes "automagically", so in many cases users were left with "Unable to execute an update task" errors with little clue on what is wrong.

As usual, we collect most common errors and try to show the helpful information on them in the task log. However we can't handle all possible situations, so now you can simply see what Drop Guard tried to do and what was the output from our server directly in the task comment! 

It also makes the whole process much more transparent as you can now see all the steps (commands) performed by Drop Guard to apply an update, patch, or execute an action.

Just search for the little "Log" link next to the problematic task comment and check the output.


Bonus hint: are you concerned about privacy? Did you know that it's not necessary to give Drop Guard full access to your codebase? Just a repo with composer files is enough for Drop Guard to operate.


So this is our first update for this year. Stay tuned for more news coming really soon and don't forget to mention your favourite next (or current) Drop Guard feature in the comments - we'll have an open ear and mind for you!