Instead of patching the path to /public in Discourse's sources, make
the nginx configuration refer to the symlink in the discourse
package which points to the real path.
When there is a mismatch between the path nginx serves and the path
Discourse thinks it serves, we can run into issues like files not
being served - at least when sendfile requests from the ruby app are
processed by nginx. The issue I ran into most recently is that backup
downloads don't work.
Since Discourse refers to the public directory relative to the Rails
root in many places, it's much easier to just sync this path to the
nginx configuration than trying to patch all occurrences in the
sources. This should hopefully mean less potential for breakage in
future Discourse releases, too.
Change the path to the public directory reported by Discourse
to its real path instead of the symlink in the store, since
the store path won't be matched by any nginx rules.
Fixes#142528.
Discourse normally overrides the default notification email setting,
which makes the `notificationEmailAddress` setting ineffective. Add a
patch to remove this override.
Fixes#140114.
When restoring a backup, discourse decompresses the backup archive in
the /share/discourse/tmp dir. Before this change, it is linked to /run
which is typically backed by memory, so the backup will fail to
restore if you do not have enough memory on your system to contain the
backup. This has already happened to me on two small forums.
This moves tmp to the StateDirectory /var/lib/discourse/tmp which is
typically backed by disk.
Some plugin repos already have a `gems` directory. This lets the
packager choose whether it should be kept and the nix packaged ruby
gems should be copied into it or if it should be removed in favor of
our ruby gems.
Perform the tests on the package that the `tests` attribute is a child
of, i.e. if `discourseAllPlugins.tests` is built, the tests will run
with the `discourseAllPlugins` package, not the `discourse` package as
previously.
Some discourse plugins have Ruby dependencies and require a
specialized builder. This introduces a generic builder that can be
used whether the plugin has Ruby dependencies or not. It also adds a
set of pre-packaged plugins available through `discourse.plugins` and
provides an easy way to add more.
For plugins to work properly, their assets need to be precompiled
along with the rest of Discourse's assets. This means we need to build
new packages when the list of plugins change.
