# Why is "rebuild" so tightly coupled to container run status?

**URL:** https://meta.discourse.org/t/why-is-rebuild-so-tightly-coupled-to-container-run-status/136414
**Category:** Development
**Created:** [18 בדצמבר,‏ 2019,‏ 4:21pm UTC](https://meta.discourse.org/t/why-is-rebuild-so-tightly-coupled-to-container-run-status/136414 "2019-12-18T16:21:53Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![lucasbasquerotto](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lucasbasquerotto/32/133376_2.png) [@lucasbasquerotto](https://meta.discourse.org/u/lucasbasquerotto)
#### Post date: [19 בדצמבר,‏ 2019,‏ 2:07pm UTC](https://meta.discourse.org/t/why-is-rebuild-so-tightly-coupled-to-container-run-status/136414/4 "2019-12-19T14:07:02Z")

</div>

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:

> [@Bootstrap app container in 2 steps](https://meta.discourse.org/t/bootstrap-app-container-in-2-steps/116865):
>
> In [this topic](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205) @sam said: Internally when we deploy we use a “pre-bootstrapped” image as our base image and then simply run “assets:precompile” and “rake db:migrate” as our only bit of custom bootstrapping code. Is there an official template for doing that? It seems that there isn’t. To achieve it I dismembered the web.template.yml in web.template.validate.yml, web.template.build.yml and web.template.run.yml. The validate image only do some validations of env variables and the like (they ar…

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.

---

_[View the full topic](https://meta.discourse.org/t/why-is-rebuild-so-tightly-coupled-to-container-run-status/136414)._