Skip to main content

Status | Drop Guard

We've found and fixed a nasty UI bug on the "Events" page of a project. If you added the "Testing with external tools" action there, your browser took an unwanted break. Now, everything works properly.

Thanks to our users, we solved the incorrect behaviour, which led Drop Guard to create tasks for all modules, even when a user didn’t select the related update type in the “Update behaviours” settings.
So while the update type has been disabled, tasks have been created nethertheless. That led to the situation, that all events settings for these tasks couldn’t be executed - no tickets, no mails.
Now the bug is solved and Drop Guard will create tasks for all modules - even if a user skipped the type of a task in the update behaviours settings.

Have you wonder why you could create a test tasks in your events settings for JIRA but you received the message, that JIRA is not connected, although Drop Guard is pretty well connected to it? Well, after a look into the code, this flaw belongs to the past now!

Have you ever experienced a case when the update task is ready to be executed, but you decide to change some update behavior settings right before execution? Like, for example, change the target branch name. But in order to change it, the old task had to be closed, settings changed and the task had to be re-created. Such a waste of time!

Last week some users experienced issues with Drop Guard not being able to recognize Drupal core and contributed modules updates in time, with delays up to a full working day.

Drop Guard operations team performed all necessary actions to identify the cause and resolve the issue as fast as possible and monitors the situation closely this week to prevent similar interruptions in future.

We have taken measures to increase the capacity of workers depending on cron jobs and added extra external monitoring checks to decrease the operations reaction time.

In some cases, a feature branch, created by Drop Guard, might not be properly deleted from the remote repository after merge action. This issue is now resolved.

Did you know that you can execute the desired Action only once per group of simultaneously running update tasks? Really handy if you send deployment requests to an external service or notify your staff about certain events via email.

On the Events configuration screen, open a supported Action and enable a checkbox. This Action will be executed in 5-10 minutes after all your update tasks in a batch are executed. Simple as that!

Due to our latest changes to the payment gateway integration, some of the payments for April may be fully authorized (processed) on May 15.

Did you now that you can click on that little question mark icon in the top right corner of the screen to get extra information about the page you're on at the moment?

In case we don't have a special help section for this page you will be redirected to the Drop Guard Docs main page.

You can now check if Drop Guard has write permission to your repository before executing your first update task.
When creating a project, Drop Guard checks for write permission automatically by doing and undoing a small commit to a live site branch. If your project is created, you can check for write access at any time by going to the Project Edit >> Basics tab.