1. Update types
Every update can be assigned a specific “Update type”, which is categorized just like the official Drupal security risk levels. These Update types contain the levels Highly Critical, Critical, Moderately Critical, Less Critical and not Critical. Although, you can configure Drop Guard’s behavior for update types which are not related to security risks. For example, you may have “Normal” updates for your projects as well. Those, as well as security-related risk levels, are called the “Update types” in Drop Guard.
2. Update behaviors
We call the configuration of the specific “Update types” (described above) “Update behaviors”. By configuring the update behavior, you can specify Drop Guard’s behavior when an update got released on drupal.org. You can configure the branch for each update type, the process for failed patches and decide the level of automation within the process.
Drop Guard creates “Tasks” which are the update jobs that need to be done to process a single update, according to the configuration. These update tasks can be processed manually (by executing them from the interface in “Tasks overview”), or automatically as soon as the update got detected.
An Event is one stage of your update pipeline. It starts with the stage that an update is available and covers the interaction with stages like failed patches or passed tests etc. When an update is processed - f.e. when Drop Guard pushes the updated version of a module to your git repository, or the QA team sets the update task status to “Test passed”, or the patch fails - you can tell Drop Guard what to do in such cases by adding specific Actions to every single Event. Learn how to set up Actions on the Events page.