mattermost 8.1.10 → 9.5.1

[stuebinm]

Description of changes

This jumps Mattermost ESR Versions (see here for their release cycle). The new version makes use of Go's workspace feature, which unfortunately the buildGoModule function does not (yet?) support, which breaks our previous build process for mattermost.

Further, the new release also makes use of private modules only included in the (non-free) enterprise version of mattermost which makes it impossible to build in the usual way even outside of nixpkgs's build abstractions if vendoring is required.

Both issues can be solved by using Go 1.22, which has added support for vendoring when using workspaces, and instructing it to ignore missing module errors with the -e flag (this works via the new go work vendor command; the "missing" modules turn out to be unimportant during the build, so it still succeeds). This requires overriding the go-modules derivation's buildPhase via overrideModAttrs. The resulting binary passes the nixos tests, and I have deployed on a production server without issues.

Additionally, @emilylange showed me how to use passthru.updateScript, so this PR incorporates this as well. Previously, the versions of mattermost in nixpkgs always tended to lag behind upstream's released versions a little by a minor (security-patch) version or two, and it'd be nice to improve this situation & hopefully this will help.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
    • Note on this: I'm not sure what constitutes "major" here — is it enough that e.g. downgrading might be hard after a database migration?
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[stuebinm]

oh, one more question: adding "cmd/mmctl" to the subPackages attribute of this package builds a working version of the mmctl cli admin tool, which is currently packaged separately in nixpkgs although it lives in the same upstream git repository as mattermost itself.

Is there any benefit to having it separate, or would it make sense to merge these two packages & add an alias for the mmctl package onto mattermost?

(cc @mgdelacroix @ppom0 since you are maintainers of the mmctl package)

[ppom0]

hi @stuebinm, when I added mmctl to nixpkgs, it was in its own repo, so it's a historical reason. however, I see a disk space benefit in keeping it separated: mmctl is genereally used on the admin's desktop, not on the instance server, so the mattermost binary would be useless there. what do you think?

[numinit]

Does the NixOS test for Mattermost still pass? :-)

In other news I'd like to get this one done for 24.05, since that has an integration test for plugin support:

#208181

[stuebinm]

@ppom0 hm, I see, that's indeed a reason. But perhaps it would be an option to define the mmctl package as an override / variant of the mattermost package, so there's no doubled effort in maintaining / updating them? (especially seeing how their versions are also currently out of sync)

[emilylange]

But perhaps it would be an option to define the mmctl package as an override / variant of the mattermost package, so there's no doubled effort in maintaining / updating them?

grafana-loki and promtail do this, just for reference :)

[ppom0]

Yes, it would be great indeed!

[stuebinm]

should i just do that here in this PR as well? (feels like a slightly different thing, so if it's preferred I'd be happy to open a second PR after this one's been merged)

also @ppom0: while doing that, should I add you as maintainer for mattermost, since maintaining mmctl and mattermost would be one and the same afterwards?

[emilylange]

should i just do that here in this PR as well? (feels like a slightly different thing, so if it's preferred I'd be happy to open a second PR after this one's been merged)

I would recommend keeping this PR to the bump itself and then creating another PR for other changes, such as making mmcli depend on the mattermost derivation.

Will hit the merge button now, but let this not prevent you from discussing details about the mmcli-thingy with one another :)

[ppom0]

@stuebinm I prefer not to be added as a maintainer, thanks for asking!