1

Previously I periodically updated Drupal sites by using a cron-job with a "drush up -y" script running every Wednesday 15,16,17,18,19,20,21,22 hours UTC. which is when "Security releases happen" according to https://www.drupal.org/node/1173280

Lately I noticed that when security issues are really urgent, the update can take place just any time during the week. I now let the update cron take place every hour every day. I am aware this is not an ideal solution. What is the better solution to update Drupal with a cron script say within the hour of any release?

closed as too broad by mradcliffe, DRUPWAY, sanzante, kiamlaluno Apr 23 '18 at 15:56

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You seem to have a custom local cron-job that doesn't have anything with how Drupal or Drupal updates work. There is no such a thing as update window as the new releases are rolled out publicly and anyone after that can run update any time. – AltaGrade Mar 31 '18 at 14:07
  • Updates are not automatic. – Kevin Mar 31 '18 at 15:35
  • Clarifying: the update manager module will tell you (in the admin) when critical updates or updates are available for core or contributed modules. But nothing will automatically update it all for you. You can also have the system email you when updates are found, too. – Kevin Mar 31 '18 at 15:51
  • @Kevin If you add that Wednesday is when the Security Team makes public any security issue on covered third-party modules, you get a pretty answer. Do you care to write it? – kiamlaluno Apr 1 '18 at 1:44
  • I don't want to defend here if updates are automatic or not or if they are appropriate or not. I just made a cron script using drush up -y and that is my choice, not under discussion here and hardly an answer to the questions. – ñull Apr 2 '18 at 7:59
1

How can we automate our updates when these exceptions take place?

Updates are not automatic. The update manager module will tell you (in the admin) when critical updates or updates are available for core or contributed modules. But nothing will automatically update it all for you. You can also have the system email you when updates are found, too - per site. This is also helpful for staying informed.

You could theoretically "auto update" with a CI/build workflow that builds X times per day, but there is more inherent risk there of breaking the site unless you are strict about versions of contrib, and specify drupal/core as ~8.0 and minimum stability stable. Though, that is not bulletproof. In the last update from 8.4 to 8.5, I had to patch over a contrib module due to a change introduced in core. That contrib module still has not updated to comply with the change. If I had this sort of workflow, core would have updated and broke the site. That isn't so much the fault of core, but the contrib module(s) not keeping pace with the changelog or the sometimes unfortunate BC breaks.

While auto update sounds like a good idea, its usually not worth the mentioned risk. I prefer to clone locally and run through the application to see if anything has changed, moved, or flat out broke instead of have it hit production immediately. I think most would agree.

With this latest PSA, everyone was given a weeks notice that it was coming so people could prepare and plan their release window around it. So there should have been plenty of time to stay informed, and most hosting companies (i.e.: ones who promote Drupal) should have notified their customers.

Wednesday is when the Security Team makes public any security issue on covered third-party modules.

  • 1
    Also, there is a setting for the security announcements newsletter in your drupal.org profile settings, at drupal.org/user/YOURUSERID/edit/newsletter - In case you have it switched off, you can enable it again there. – rooby Apr 2 '18 at 11:21
  • What if the user / administrator decides to take the mentioned risks, when he find security to be updated more important than security that it is working? This is the reason I use cron jobs. – ñull Sep 19 '18 at 18:07
  • @ñull – Then simply let a cron job periodically run composer update or drush up or whatever routine you want. NOT RECOMMENDED! – leymannx Sep 19 '18 at 18:56
  • 1
    I can't understand why you'd risk taking down a production site at any moment (as well as change the codebase) without being present. I just can't see any good scenario for this, not to mention the fact that you can't easily roll back the code, so I think this should stand as a warning for anyone coming around and reading. – Kevin Sep 19 '18 at 19:04
  • 1
    Thats understandable but the whole thing sounds like "how do I pull the trigger automatically on prod" which I think should be advised against for a majority of viewers who arent in devops. Doing this at a lower level, having tests, a build process and notification setup that would be fine. I assume that most do not. – Kevin Sep 21 '18 at 13:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.