When will the update process automatically handle dependencies

Seems our instance has just updated to 1.44, and yet again, it failed as there were several missing dependencies. I’d previously been on the dev track, which is no longer the case, so I think it’s reasonable to expect some level of stability when updates occur, in particular when seemingly trivial things such as simply only updating additional packages is required.

Can a trigger be placed that when these updates are done, it will automatically run the appropriate script? What I don’t want is to come in the morning and be asked why it’s not working.

I suppose I can just not update it automatically…but why create more work?

I doubt that’s ever going to happen. We run as a restricted user which won’t have access unless we use sudo, however even if we did - we have no idea what the package name will / should be to say install mbstring.

What dependencies were you missing?

As for which, why not a self validation and run the appropriate script? As far as user permissions, if that’s a show stopper, then perhaps some process that won’t kill the site as a whole, instead, some text that shows the below…or something to that effect. Basically, some better method to indicate to the end user that something exploded, and some manual intervention is required.

[FAIL]  Missing dependencies! [FIX] ./scripts/composer_wrapper.php install --no-dev
         fideloper/proxy
[FAIL]  Outdated dependencies [FIX] ./scripts/composer_wrapper.php install --no-dev
         vlucas/phpdotenv
         symfony/css-selector
         symfony/polyfill-mbstring
         symfony/var-dumper
         symfony/process
         symfony/polyfill-ctype
         symfony/polyfill-php70
         symfony/http-foundation
         symfony/event-dispatcher
         symfony/debug
          and 11 more...
[OK]    Composer Version: 1.7.2
[FAIL]  Missing dependencies!
        [FIX] composer install --no-dev
        Dependencies:
         fideloper/proxy

All of those we do handle, you should look at logs/daily.log to see what’s gone on.