I’m not sure about your yml, I would say it has indentations errors. And why do you have two times the “any custom command section” ?
I ended up completely reinstalling the server and I got it to add the plugin without an error this time. However the plugin is not clickable. I briefly tried the dicourse free trial that had everything already installed and I was able to click the plugin and change settings.
That’s because you’re not using the official version of the plugin, but a old forked copy that hasn’t been updated since 2015. Update the link in your
app.yml to point to
Okay, where can I find active plugins?
I try to search for them here and can’t figure out how to sort between links to plugins and just topics about them. I ended up just searching directly on github, but looks like I am ending up with outdated plugins.
I’d suggest reviewing the #plugin here on Meta, making sure to avoid the #plugin:broken-plugin subcategory. Within the plugin category, the #official tag denotes a plugin maintained by the Discourse team. We ensure the plugin works with the latest version of Discourse, and will fix bugs that are found. Other plugins are maintained by community members, so you’ll need to work with them to address bugs/issues.
Isn’t the github URL path the simplest and most obvious way to determine this?
If the plugin is in the discourse org…
then it is official.
If not… then it is not
I know I mentioned that I’ve been using the token method for installing private plugins, but when building plugins for clients I’ve learned that I don’t want to use a token from my own GitHub account. The client would then have access to all the repos I have access to.
An alternative has been to set up a machine user and grant that user a token that can be used once the machine user is made a collaborator on the private repo. But I don’t really feel like paying for an extra collaborator seat for each machine user.
I still use tokens on demo servers, but for production scenarios, I went back to the original way of installing private plugins. I did run into issues with the original instructions. What eventually worked for me was the following:
## Remember, this is YAML syntax - you can only have one block with a name run: - exec: echo "Beginning of custom commands" - exec: cd /var/www/discourse && sudo -u discourse bundle install --deployment --without test --without development - exec: mkdir /root/.ssh - exec: chmod 700 /root/.ssh - exec: echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config - file: path: /root/.ssh/id_rsa chmod: 600 contents: | -----BEGIN RSA PRIVATE KEY----- -----your private key string----- -----END RSA PRIVATE KEY----- - file: path: /root/.ssh/id_rsa.pub chmod: 600 contents: ssh-rsa ---your long string--- user@discourse - exec: cd $home/plugins && git clone firstname.lastname@example.org:USERNAME/REPO-NAME.git - exec: cd $home && sudo -E -u discourse bundle exec rake db:migrate - exec: cd $home && rm -fr tmp/cache - exec: cd $home && sudo -E -u discourse bundle exec rake assets:precompile - exec: rm /root/.ssh/id_rsa - exec: rm /root/.ssh/id_rsa.pub - exec: chmod 600 /root/.ssh - exec: echo "End of custom commands"
But aren’t you now giving them your ssh key, which still gives them access?
I’m generating a key specific to that scenario and adding the public key as a deploy key on the repo. So it’s not the SSH key of my machine.
I have installed a couple plugins and now want to add another. Do I remove the already installed ones from the app.yml of just add the new ones at the bottom?
Unless you want to uninstall the other plugins, you want to keep them in your
Good to know, thank you!
The downside of using deploy keys to install a private plugin via custom commands is that you can’t upgrade the plugin via
@mpalmer How hard would it be to allow for plugins installed via custom commands to be “upgradeable” via
Very difficult. Give it a shot if you like, but it’s a tricky problem. The best option is to switch to using oauth tokens (with all the security/cost tradeoffs that GitHub’s scopes inflicts).
@molly_cushing, Your post was exactly what I needed! Thanks for putting this together.
I personally learn the best by watching someone do something so I created a video tutorial following the steps you outlined, for anyone who’d like to see the process in action:
I’m beginer in Discourse, and after cloned Disourse repository, can’t find container/app.yml fie.
Do I have to create new one?
And also the command “./launcher rebuild app” isn’t working cause there isn’t such file or directory named “launcher” in the project
Sounds like you didn’t fully installed Discourse, you need to follow all these commands : discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub
After that, and only after, you can run these commands to install a plugin. You need to be in the discourse folder :
After that, you can open the app file using nano
And still in the /var/discourse folder, you can run the command to complete the install (this command will take a few minutes)
./launcher rebuild app
There’s actually no need to
sudo -s when updating your app.yml, a simple
sudo nano containers/app.yml from within /var/discourse will suffice.
The ‘git pull’ is redundant here too.
@sivert If you ran discourse-setup as outlined in the official install guide an app.yml would be created for you at /var/discourse/containers/ with all the necessary settings to get Discourse running. Have you already done this? If so you need to move to /var/discourse before issuing the commands you mentioned above, a simple
cd /var/discourse will suffice.
as … means ‘up a level’ it’s very rarely going to be the right way to get there.
@Stephen Thanks for your answer. It seems I was confused between dev and pub versions.
Just now I was working on developing version in my MacOS system.
Can I continue follow this guid to test my plugins on developing version or is this thread for only production version and I have to find another way?