Installing a particular commit of a plugin?

(James Kiesel) #1

Hey Discourse!

So, I’ve got a shiny new version of Babble which I’d like to throw up onto my instance, but I don’t want to merge it into master and make it available to anyone upgrading yet. Could someone point me towards the commands I can use to specify a particular branch / commit hash to apply the plugin with?

Installation Error when rebuilding with Discourse Official Plugins (Discourse v2.0.3)
Babble - A Chat Plugin [ARCHIVE]
(Alan Tan) #2

You might be able to do something like this.

    - exec:
        cd: $home/plugins
          - mkdir -p plugins
          - git clone
          - cd docker_manager
          - git reset --hard <commit ref> # or whichever git command you need to apply here.
          - cd ..

Use old commit to build discourse
(Erlend Sogge Heggen) #3

Testing bleeding-edge versions of your plugin without disrupting your users is another very valid use case in favour of improving plugin compatibility checks:

(Allen - Watchman Monitoring) #4

Here’s how @cpradio points out we can do this:

git clone --branch v0.2.1

And that’s worked for me.

(cpradio) #5

Just for clarification, the context of mine was to help those who did not want to run against tests-passed, the default branch Discourse ships with. So I branched/tagged my current version of ‘master’ as v0.2.1 (a specific point in time) and had anyone running stable refer to that branch in your app.yml

Context at

Likewise, if you are wanting to run a specific branch on a production site, you can simply reference that branch in your app.yml. Just realize that depending on the changes, you might not have a feasible way to revert back to your master branch (if you change your data structure, for example).

The route you take, branching/tagging master at a point in time (for those running off of stable), versus telling early adopters to reference a specific branch, depends on your circumstances.

(Bart) #10

Is this still the recommended way of doing it? I need to roll back to a previous version of a plugin.

(Sam Saffron) #11

My recommendation here would be to fork the plugin and install the fork, that way /admin/upgrade will continue working and your app.yml will be significantly less unwieldy