`yarn run patch-package` as `postinstall`-hook doesn't work because it
has a shebang using `/usr/bin/env` which isn't available in the sandbox.
Removing the postinstall hook and manually running this after
`patchShebangs` appears to solve the issue.
Relevant error log of the build error
(`NIXPKGS_ALLOW_INSECURE=1 nix-build -A discourse.assets`)
error /build/source/app/assets/javascripts/node_modules/discourse: Command failed.
Exit code: 127
Command: patch-package
Arguments:
Directory: /build/source/app/assets/javascripts/node_modules/discourse
Output:
/bin/sh: line 1: /build/source/app/assets/javascripts/node_modules/.bin/patch-package: cannot execute: required file not found
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
...in the update script and remove it from the Gemfile.lock. Having
it there causes a failure with the error message:
Could not find libv8-node-16.10.0.0-aarch64-linux in any of the
sources (Bundler::GemNotFound)
And since we're not using the prebuilt binary packages anyway, we
don't need it there in the first place.
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.
Add a DiscourseVersion class which handles Discourse's version
numbering properly when sorting - beta versions are sorted lower than
their respective release versions. It can also return both its version
number and equivalent git tag, removing the need for `rev2version` and
manually adding `v` to the front.
Using DiscourseVersion instead of LooseVersion, we can list all
current version number tags from the `discourse` repo and sort them
correctly, giving us the latest one, regardless of type; i.e. we don't
have to filter for only release versions or beta versions anymore.
This also implements the plugin pinning algorithm laid out here:
https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971
to make sure we don't upgrade plugins further than what's compatible
with our currently packaged Discourse version. While it likely won't
matter much most of the time if we continue packaging the beta
versions, it could be helpful if we decide to go back to packaging
release versions or if we run into issues with future upgrades. In
that case, the plugins could still be updated safely even though we're
not on the latest version of Discourse.
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
