The server try.thepavilion.io serves three interconnected purposes:
- A CI server for Pavilion’s Discourse plugins and themes.
- A staging server for the users of Pavilion’s Discourse plugins and themes.
- A test server for people who want to try out Pavilion’s Discourse plugins and themes.
Setup
Try has three customisations, apart from the plugins and themes it’s testing. Together they combine to support the three purposes mentioned above.
Plugin guard
https://github.com/paviliondev/discourse-plugin-guard
This is not a discourse plugin per se. It’s a bundle of files which are used to implement plugin error handling on try.
The repository is cloned into the /var/discourse/shared/standalone folder on try.thepavilion.io (so its files are available to both the host and the container), and its files are inserted into different aspects of the server and discourse app on that server.
Whenever the plugin guard is updated, the repository at /var/discourse/shared/standalone/discourse-plugin-guard needs to be updated via git pull
.
templates/plugin_guard.template.yml
This is a Pups template that is added to the app.yml file on try.thepavilion.io. It basically adds some bash commands to the discourse startup processes to handle the insertion of the plugin guard files into the right place in the discourse folder structure.
The plugin guard files need to be inserted via this method as the plugin guard needs to be in place when the startup process reaches the point of loading the plugin files. This means the plugin guard can’t be a normal Discourse plugin.
lib/plugin_initialization_guard.rb
This file overwrites the existing lib/plugin_initialization_guard.rb in Discourse (which is what handles serverside plugin incompatibility in core Discourse and throws the PLUGIN INCOMPATIBILITY message if there’s a serverside issue with a plugin)
Rather than causing the startup process to fail if there’s an incompatible plugin, this new guard moves the incompatible plugin to a seperate folder plugins_incompatible
and sends and email to the site contact
jobs/send_plugin_incompatible_notification.rb
This handles the sending of the email mentioned above. The mail is sent to the site contact (set in the contact email
site setting), and is from the site notification email (set in the notification email
site setting).
Note that in order for the emails sent by this process to be ingested into a discourse group mailing list like dev@thepavilion.io the sender email (i.e. the site notification email) has to be added to the receiver instances’ auto generated whitelist
site setting.
Server status
https://github.com/paviliondev/discourse-server-status
This is a discourse plugin that creates the “Status” panel you see in Try’s discovery view
The point of having this here is to make a few things clear:
- What commit/version the site is on
- Which plugins are installed and which are compatible
- Other helpful links to serve the goals of Try
Chron job
The try.thepavilion.io server has a chron job set to run every 24 hours that rebuilds the instance entirely. If you ssh into the server and open the chrontab
crontab -e
You’ll see the following
0 00 * * * /usr/local/bin/rebuild_discourse >>/tmp/cron_debug_log.log 2>&1
(for more on cron job syntax see CronHowto - Community Help Wiki)
The script at /usr/local/bin/rebuild_discourse
looks like this
cd /var/discourse
./launcher rebuild app
This basically means that every day at 00
hours UTC time Discourse will be rebuilt and the logs wil be piped to /tmp/cron_debug_log.log