About updating discourse source, os level dependencies, the docker base image, ruby gems and the like, it’s possible to do that making the build in 2 steps, and run the aforementioned tasks in the 1st step.
This first step is agnostic to the environment and could be run even in a CI environment (so you could use an almost identical image in staging and production environments, avoiding possible errors due to rebuilding in different dates, not to mention the reduced downtime).
The db migration and assets:precompile tasks would still need to be run in the target machine. The db migration in most cases would be fast. On the other hand, the assets:precompile task is a problem because it is the step that takes more time. I think it’s because some assets need to know some environment stuff as defined in the db, like some css rules, to execute.
It would be very very great if this task were to be divided in 2 where all assets that don’t depend on the environment run first, and could be run in a CI environment, and in the 2nd step it would compile only assets that depend on stuff in the db, etc… That said, I don’t know how hard, technically, it would be to implement it.
I discuss about bootstrapping the app container in 2 steps in the following topic:
The changes I made were only about dividing the discourse web template in 3 files, but the tasks are the same, although it would be great if the discourse team supported it so that I wouldn’t need to update them due to future changes in the web template.