How you can handle your patches easily - Drop Guard recipe
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 an fully or partly automated update process.
1. Update release
An update got released on Drupal.org. 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 prefered 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.
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:
- Drop Guard clones your git repository
- Then downloads the original version of a module/core from Drupal.org
- Calculates the diff for module/core
- Saves this as a patch
- Then downloads the new version of the module/core into your repository (all files will be changed to new version)
- 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 get automated) and you will get a nice overview on what was patched and a full auto generated 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.
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.