try.thepavilion.io

Knowledge Support
#1

The server try.thepavilion.io serves three interconnected purposes:

  1. A CI server for Pavilion’s Discourse plugins and themes.
  2. A staging server for the users of Pavilion’s Discourse plugins and themes.
  3. 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

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

This is a discourse plugin that creates the “Status” panel you see in Try’s discovery view

Screen Shot 2020-06-10 at 3.06.51 PM
Screen Shot 2020-06-10 at 3.06.51 PM2252×930 262 KB

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

1 Like