Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake assets:precompile'"]}
f565d457b97d7ff12a258b03a456563a5a0e928c707c70e194ef88ba170aaf3a
**FAILED TO BOOTSTRAP** please scroll up and look for earlier error messages, there may be more than one
```
I have disabled all plugins, still no joy. Can anyone shed any light on this?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 11, 2019, 11:11pm UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/2 "2019-12-11T23:11:10Z")
We saw this before somewhere else.
Can you try
```plaintext
./launcher cleanup
git pull
./launcher rebuild app
```
If that does not work try removing all the containers on the machine and all images.
---
### Author:  [@russellwstanley](https://meta.discourse.org/u/russellwstanley)
#### Post date: [December 12, 2019, 8:37am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/3 "2019-12-12T08:37:54Z")
Thanks for the quick response @sam . I will try that.
Quick question. The “git pull” I am assuming pulls the latest version of discourse-docker right?
In general, is it necessary to upgrade discourse-docker and discourse at the same time?
Currently, I don’t have discourse-docker controlled by git. Instead, I download a specific revision of discourse-docker (as a Zip) when configuring the server and pin the version of discourse to a specific commit during deployment of discourse.
The reason I do this is in order to try and make the build repeatable ie. running the same command with the same configuration + source at 2 different times should produce the same artifact. In general this is a good idea and has got me out of loads of ops nightmares with other software over the years 😉 This is because it gives you the ability to roll back to a known good configuration.
However, I think I’m swimming against the tide here with discourse because it seems to want to pull the latest versions of various bits of software during the build. I’m starting to wonder if my attempts to make the build repeatable are actually shooting myself in the foot?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 12, 2019, 9:39am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/4 "2019-12-12T09:39:22Z")
> [@russellwstanley](#):
>
> I think I’m swimming against the tide here with discourse
Very true words you have entered a 100% unsupportable state with this hackery 😳
Recommend you pull latest from git asap
Old docker images of discourse base are incompatible with current discourse, plus they are missing many security patches
---
### Author:  [@russellwstanley](https://meta.discourse.org/u/russellwstanley)
#### Post date: [December 12, 2019, 9:50am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/5 "2019-12-12T09:50:39Z")
Thanks @sam. I’ve done that and I am able to build the new version now. Fortunately, this was all on beta so no harm done 🙂 I’m not sure it is “hackery” to want a repeatable build though 🤔
The thing I am trying to get here is the ability to roll back to a known good version. Suppose that I run ./launcher rebuild app at time t1 and discourse works. I then run ./launcher rebuild app at time t2 and something is wrong. How do I get the software back to the previous version? I think I could live with the fact that the build is not repeatable if I could roll back to a known good state. Since the launcher has already built a working docker image at time t1, is it possible to tell the launcher to use a specific image rather than the bad one that was built at time t2?
Any ideas?
Sorry for going a bit off topic on this, I can re-post if you like.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 12, 2019, 9:57am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/6 "2019-12-12T09:57:27Z")
If you want repeatable builds you got to pin your discourse version to a specific sha via your container config, and every plugin
That means you stop getting fixes to discourse, security fixes to docker image and so on, but the build will be pretty repeatable
You may need to amend templates as well to fossilise stuff and never take in security fixes to apt dependencies
---
### Author:  [@russellwstanley](https://meta.discourse.org/u/russellwstanley)
#### Post date: [December 12, 2019, 10:01am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/7 "2019-12-12T10:01:38Z")
Ok, I already pin the version of discourse to a specific commit and I can also do this for plugins. But if I don’t also pin discourse-docker, won’t this result in a situation where discourse-base gets updated on every build but discourse does not. Won’t that just result in a similar incompatibility but the other way round (because discourse-base gets in front of discourse)?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 12, 2019, 10:07am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/8 "2019-12-12T10:07:44Z")
I am confused, how did this error show up if you have discourse pinned to something old?
If NGINX has a critical vulnerability do you want that fixed?
---
### Author:  [@russellwstanley](https://meta.discourse.org/u/russellwstanley)
#### Post date: [December 12, 2019, 10:34am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/9 "2019-12-12T10:34:08Z")
The error showed up when I moved the pinned version of discourse forward from 2.4.0.beta2 to 2.4.0beta8
Yes of course I would like to have critical vulnerabilities in dependent software systems fixed when I run a new build! Sounds Fantastic!
However, I would also like to be able to roll back in the case where the new version is broken 🙂
Let me run a concrete example:
suppose my configuration is in the current state:
discourse : 2.4.0beta2 (pinned in web\_only.yml)
I run ./launcher rebuild web\_only and everything works.
now my system is in this state:
discourse : 2.4.0beta2
discourse-docker: LATEST-AT-TIME-T1
so now I change my configuration to this state:
discourse : 2.4.0beta8 (pinned in web\_only.yml)
I run ./launcher rebuild web\_only and something is broken.
My system is now in this state:
discourse : 2.4.0beta8
discourse-docker: LATEST-AT-TIME-T2
So now I want to go back to the previous version to get everything working again. So I change the pinned version of discourse to 2.4.0beta2 and rebuild. However when I run ./launcher rebuild web\_only, the system is now in this state:
discourse : 2.4.0beta2
discourse-docker: LATEST-AT-TIME-T2
Although the pinned version of discourse is the same, the version of discourse-base (and the rest of discourse-docker, templates , the ./launcher itself etc) will now be different, so I won’t be rolling back to a known good state, and I would worry that it would not build at all.
Sorry if I’m being dense here, all I want to do is to have the ability to get back to safety in case there are problems during an update. Perhaps re-running ./launcher rebuild web\_only is just not the right way to roll back here? For other systems that I deploy, I would just re-deploy a previous docker image? Is there a way to tell the launcher to do this?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 12, 2019, 10:48am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/10 "2019-12-12T10:48:41Z")
yeah, you got to rethink your process here. Our db migrations are not reversible.
If you want to test out an upgrade without committing you need to operate in a staging sandbox
---
### Author:  [@russellwstanley](https://meta.discourse.org/u/russellwstanley)
#### Post date: [December 12, 2019, 10:58am UTC](https://meta.discourse.org/t/error-on-building-latest-version/135706/11 "2019-12-12T10:58:20Z")
Yea, I understand that it is difficult to roll back a db migration. Discourse is obviously not built with my kind of release and deployment management strategy in mind. I should stop swimming against the tide here.
I have a staging environment. So I’ll just abandon any ideas of repeatable build and deployment, test on staging and then cross my fingers and toes when moving to production.
Thanks for your help @sam