How you can handle your patches easily - Drop Guard recipe

Drop Guard recipe - patch handling
Update automation sounds nice as long as you don’t think about your (heavily) patched Drupal project, right?
In this “recipe” I will explain how Drop Guard handles custom patches within a fully or partly automated update process.

1. Update release

An update got released on Only a few minutes later, Drop Guard detects the update release information, such as update type and version.


2. Update behavior & configurations

On the Site config tab, our users adjusted the preferred behavior of Drop Guard for each type of updates: Highly Critical, Critical, Moderately Critical, Less Critical and Not Critical security updates as well as “Normal”, which means “Non-Security” updates.
This means that you can control on which branch an update will be applied if a feature branch should be created,  manual testing options, which level of auto-commit you prefer, how to handle patches (we will focus on that in this post) and also if you want to create a git tag.


Update behaviors page


3. What happens when a patch couldn’t be applied?

At this point, the main goal for Drop Guard is that your individual changes will be re-applied as patch within an update process.
So, when you store your modules directly within your git repository, the general workflow is:
  1. Drop Guard clones your git repository
  2. Then downloads the original version of a module/core from
  3. Calculates the diff for module/core
  4. Saves this as a patch
  5. Then downloads the new version of the module/core into your repository (all files will be changed to a new version)
  6. And finally tries to re-apply the patch, which was created in step 4, on top.
With this mechanism, no code modifications will get lost after updates have been processed.
In the case of success, the update is considered as “ready to test” or “test passed” (it depends on your settings in Drop Guard and how much you would like to get automated) and you will get a nice overview on what was patched and a full autogenerated patch output.
In case the patch fails to apply, the update process stops, and you get a notification about the “Error” with a detailed log file.
Then it's up to you to decide whether to stop the update process and review what went wrong or to proceed, discarding your modifications or even exclude a module in general from update processes.

log file of patch error


So, you won’t lose individual patched modules by doing automatic updates in Drupal with Drop Guard.
By the way: with this patch detection pipeline, Drop Guard can be used to detect malicious code inserts, debug code, or accidental code modifications.
If you have further questions or if you’d be happy to get some support with your patch notifications, just contact us or join our Slack channel.