# Stable branch compatibility with discourse\_docker and plugins

**URL:** https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679
**Category:** Self-hosting
**Tags:** stable
**Created:** [5월 14, 2019, 10:54오전 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679 "2019-05-14T10:54:51Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 10:54오전 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/1 "2019-05-14T10:54:51Z")

</div>

I would like to leave some feedback about operations experience from past several years when I occasionally look after one pretty small Discourse installation:

- Single self-hosted VM
- Discourse installed via official docker setup
- 3 Official plugins

Every time it comes to updating from an older version (3-9 months old), it’s always a nightmare. I have never had a smooth upgrade that wouldn’t take days of head scratching, reading source code and forums, trying unconventional backup restore strategies, etc. So far, I have encountered these issues, some of them multiple times:

- Backup cannot be restored (into same version of Discourse backup was made from).
- updated discourse\_docker incompatible with discourse, unable to rebuild
- Plugins randomly breaking after rebuild

Discourse is an ecosystem of main app, discourse\_docker and plugins, and yet neither discourse\_docker nor plugins have any tags in github, or versioning, that would say “Discourse version x.y.z will definitely work with discourse\_docker version x.y.z and plugins that have version x.y.z”.

Proposed solutions:

- Have CI setup that tests backup / restore for each release.
- Start versioning and tagging discourse\_docker and plugins in sync with discourse releases
- Have some CI to test interoperability of various ecosystem parts
- Have tests in plugins, and CI in pull requests
- Forbid committing directly to master without pull request reviews, so situations like this would not occur: [Add frozen string literal comment to files. · discourse/discourse-oauth2-basic@5a459fb · GitHub](https://github.com/discourse/discourse-oauth2-basic/commit/5a459fbb6e43f3853e10b07c116150722342feed)

When developing, please remember that not everyone is a discourse developer who is always using latest master branch from all discourse/\* repos. I hope this feedback proves to be useful.

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:13오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/2 "2019-05-14T12:13:34Z")

</div>

Which release are you running in your app.yml?

As someone who has been running discourse for six years now in a broad variety of environments none of the situations described above remotely mirror my experience.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:34오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/3 "2019-05-14T12:34:44Z")

</div>

Right now I am running v2.1.5 and trying to upgrade it to v2.2.5. And here’s an example of what I have to do for backup import to work:

```plaintext
<...>
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
ERROR: function discourse_functions.raise_email_logs_reply_key_readonly() does not exist
ERROR: current transaction is aborted, commands ignored until end of transaction block
ERROR: current transaction is aborted, commands ignored until end of transaction block
ERROR: current transaction is aborted, commands ignored until end of transaction block
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:320:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:66:in `run'
script/discourse:136:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
script/discourse:277:in `<top (required)>'
/usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `load'
/usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `kernel_load'
/usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/2.6.0/bundler/cli.rb:463:in `exec'
/usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/usr/local/lib/ruby/2.6.0/bundler/cli.rb:27:in `dispatch'
/usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/usr/local/lib/ruby/2.6.0/bundler/cli.rb:18:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:30:in `block in <top (required)>'
/usr/local/lib/ruby/2.6.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:22:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Trying to rollback...
Rolling back...
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2019-05-14-121130' directory...
Unpausing sidekiq...
Disabling readonly mode...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
root@forum1-app:/var/www/discourse# su - discourse
discourse@forum1-app:~$ cd /var/www/discourse/
discourse@forum1-app:/var/www/discourse$ RAILS_ENV=production bundle exec rails c
Loading production environment (Rails 5.2.2.1)
irb(main):001:0> require_dependency 'migration/base_dropper'
=> true
irb(main):002:0> Migration::BaseDropper.send(:create_readonly_function, ['email_logs', 'reply_key'])
=> 0
irb(main):003:0> Migration::BaseDropper.send(:create_readonly_function, ['email_logs', 'skipped_reason'])
=> 0
irb(main):004:0> Migration::BaseDropper.send(:create_readonly_function, 'topic_status_updates')
=> 0
irb(main):005:0> Migration::BaseDropper.send(:create_readonly_function, 'users_email')
=> 0
irb(main):006:0> 
discourse@forum1-app:/var/www/discourse$ logout
root@forum1-app:/var/www/discourse# discourse restore forum-2019-05-09-033432-v20180828065005.tar.gz
Starting restore: forum-2019-05-09-033432-v20180828065005.tar.gz
[STARTED]

```

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [5월 14, 2019, 12:36오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/4 "2019-05-14T12:36:15Z")

</div>

So you’re running on the stable branch?

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:38오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/5 "2019-05-14T12:38:59Z")

</div>

Another thing from same upgrade (v2.1.5). When you go to admin panel and try to upgrade it automatically, it says:

```plaintext
You are running an old version of the Discourse image.

Upgrades via the web UI are disabled until you run the latest image.

To do so log in to your server using SSH and run:

        cd /var/discourse
        git pull
        ./launcher rebuild app

```

Guess what happens if I do `git pull` in `/var/discourse` and try to rebuild? `mini_racer` gem fails to build, and I’m stuck with broken installation. I then have to find an older commit on `discourse_docker` that would work with `v2.1.5` just to be able to rebuild and make it start again. It would be easier if there were tags.

P.S. I always do upgrades in a clean VM, by first reproducing my current environment, restoring production backup, testing that it works, then upgrading it there to see if upgrade doesn’t fail. It always fails. Maybe I’m just really unlucky.

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:40오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/6 "2019-05-14T12:40:04Z")

</div>

I’m curious if you’ve been having these problems for a couple of years now why you only joined Meta two hours ago? The peer support here is generally excellent, and the first step for most when they hit any form of problem.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:40오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/7 "2019-05-14T12:40:46Z")

</div>

> So you’re running on the stable branch?

Yes, if you can call it stable 🙂  
I’m not running beta. Tried beta too a while ago btw, same experience.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:42오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/8 "2019-05-14T12:42:55Z")

</div>

> [@Stephen](#):
>
> I’m curious if you’ve been having these problems for a couple of years now why you only joined Meta two hours ago?

I’m not the forum dweller type myself. Usually it’s faster to find a solution to a problem on my own than to post and discuss it in dev forum. This time I just had to vent, with hope that discourse devs would introduce some versioning to all components, and my life would get easier for next upgrade 🙂

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:45오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/9 "2019-05-14T12:45:09Z")

</div>

That’s the point, stable in this sense means ‘infrequently changed’.

There’s good reason that so many communities are on tests-passed, including CDCK’s own hosted customers.

For the mini-racer issue, it has been resolved in this commit: [FIX: We need a newer mini\_racer for ruby 2.6.3 · discourse/discourse@99dd426 · GitHub](https://github.com/discourse/discourse/commit/99dd426b12210c93c728a6a8993b9a78430b3b5e)

> [@spajus](#):
>
> I’m not the forum dweller type myself. Usually it’s faster to find a solution to a problem on my own than to post and discuss it in dev forum. This time I just had to vent, with hope that discourse devs would introduce some versioning to all components, and my life would get easier for next upgrade 🙂

I don’t think you’ve made your experiences any easier by taking this tact.

> [@spajus](#):
>
> P.S. I always do upgrades in a clean VM, by first reproducing my current environment, restoring production backup, testing that it works, then upgrading it there to see if upgrade doesn’t fail. It always fails. Maybe I’m just really unlucky.

How do you repro your production environment exactly? If you aren’t running a staging copy in parallel you run a very high risk of just introducing more variability here.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:47오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/10 "2019-05-14T12:47:50Z")

</div>

> [@Stephen](#):
>
> How do you repro your production environment exactly? If you aren’t running a staging copy in parallel you run a very high risk of just introducing more variability here.

We have configuration management, and Chef can provision an identical VM locally, check out the production version of discourse\_docker, and build an empty forum, where I can then import the backup from production. The only moving part here is plugins, that are being checked out from master branch (because they have no tags).

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:51오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/11 "2019-05-14T12:51:32Z")

</div>

I’m curious whether your chef recipies are a factor here. The only common issue with restoring the database relates to version 1.9, which you’re well past.

---

<div class="post-metadata">

### Author: ![ChrisBeach](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chrisbeach/32/214628_2.png) [@ChrisBeach](https://meta.discourse.org/u/ChrisBeach)
#### Post date: [5월 14, 2019, 12:51오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/12 "2019-05-14T12:51:36Z")

</div>

I generally find that Discourse updates cleanly and smoothly.

Over the three years I’ve run Discourse forums there have been a small handful of upgrade problems, generally caused by third-party unsupported plugins I’d installed. Not once have I had to do anything drastic like restore from a backup. The ecosystem around Discourse (including its plugin developers) are very committed and conscientious, and problems are resolved in a matter of hours.

Coming from a corporate IT background, I find Discourse’s speed of development, and responsiveness to bug fixes is **extraordinarily good**. In my experience using open source projects, Discourse is up there with the best supported.

I would recommend against creating a complex dependency graph by emphasising version numbers. This will add extra complexity to the development process, and is only partially useful in solving compatibility problems. It’s better IMO if we have more CI going on, and if plugins are regularly tested against the latest version of Discourse core. This is the responsibility of plugin developers IMO, but perhaps CI tips and templates could be shared here for everyone’s benefit.

Discourse team - keep doing what you’re doing. It’s a fantastic project, and, remarkably - free of charge.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:53오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/13 "2019-05-14T12:53:55Z")

</div>

> [@ChrisBeach](#):
>
> I would recommend against creating a complex dependency graph by emphasising version numbers.

It wouldn’t have to be a dependency graph, For example when you release `v2.4.0` stable, just make sure that everything works, and tag everything `v2.4.0`. That way there would be no question which commit of the plugin or `discourse_docker` would work for that given version.

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:56오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/14 "2019-05-14T12:56:10Z")

</div>

> [@spajus](#):
>
> For example when you release `v2.4.0` stable, just make sure that everything works, and tag everything `v2.4.0`

Actually the primary impact of this is that it becomes slower to make fixes and enhancements available to older discourse versions. It’s really not common for plugins to be rendered incompatible by Discourse updates.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 12:57오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/15 "2019-05-14T12:57:06Z")

</div>

> [@Stephen](#):
>
> I’m curious whether your chef recipies are a factor here.

It is most likely not, all it does is install the OS, create `/var/discourse` directory, check out given commit of `discourse_docker` and fills in `containers/app.yml` template.

---

<div class="post-metadata">

### Author: ![Stephen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stephen/32/95011_2.png) [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [5월 14, 2019, 12:58오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/16 "2019-05-14T12:58:26Z")

</div>

Does it carry out all the same pre-flight checks as discourse-setup? Does it create swap?

If you sidestep the tools which validate the environment as a part of the product install, it’s harder to point a finger at the product itself.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 1:03오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/17 "2019-05-14T13:03:02Z")

</div>

It does not do pre-flight checks, not create swap. But if system runs out of memory or Docker is too old, those things are obvious, and I don’t blame Discourse for this. `discourse-setup` would not save me from plugins being incompatible.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 1:06오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/18 "2019-05-14T13:06:16Z")

</div>

Anyway, I’m not attacking Discourse developers. You guys are doing a great job, I’m just trying to suggest some changes to the development process that would make operations people lives easier.

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [5월 14, 2019, 1:19오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/19 "2019-05-14T13:19:44Z")

</div>

Thanks for the feedback @spajus. It’s always good if we can find **specific** tasks to improve the experience for users and administrators. Generalising things in one large topic makes it difficult to turn them into actionable tasks.

Looking specifically at your second bullet point. We aim for discourse\_docker to be compatible with the latest `stable`. Are you seeing something different?

> [@Stephen](#):
>
> For the mini-racer issue, it’s being investigated, but for now you can simply:
> 
> ```plaintext
> 
> ```

As far as I know, [this should be resolved](https://meta.discourse.org/t/failing-to-rebuild-app-on-discourse-since-may-7/117121/13) and is no longer being investigated. If it’s still broken, let us know. The `sed` fix is a bad idea, as it will probably break more things in future.

If chef is only provisioning an OS, and you are using `discourse_docker`, then it does seem unlikely that chef is causing the issues.

---

<div class="post-metadata">

### Author: ![spajus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/spajus/32/141021_2.png) [@spajus](https://meta.discourse.org/u/spajus)
#### Post date: [5월 14, 2019, 1:25오후 UTC](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679/20 "2019-05-14T13:25:00Z")

</div>

@david one very specific suggestion was to tag `discourse_docker` and plugins when new `discourse` stable is released, so there would be way to tell which `discourse_docker` commit is compatible with older version of `discourse`, should someone want to set it up instead of the lastest (i.e. for restoring an older backup, or to test an upgrade procedure).

The `mini_racer` issue is solved in latest `discourse_docker` and latest `discourse` stable.

UPDATE: I cannot post again for 1 day due to new user restrictions, so read the updated post to see why not everyone would always want to install _latest_ discourse.

[Next page](https://meta.discourse.org/t/stable-branch-compatibility-with-discourse-docker-and-plugins/117679.md?page=2)
