feat: mage package for plugins

[fmartingr]

Summary

• Adds a pluginmage package that can be used from plugins to maintain the toolkit up to date.
• Make targets migrated: server, proceesor, webapp, webapp/node_modules, deploy, dist, bundle, watch
• Makefile now calls mage on the migrated targets.
• PluginCTL logic has been migrated to mage directly by calling mage pluginctl:(command) and it's available to other targets as well.

Improvements

• Can run dependendant targets in parallel (server and webapp for a build).
• Friendly error codes for checks (do you have Go? Do you have NPM? Do you have GNU's Tar?) with links to documentation
• Allow the plugin developers to specify other binaries to be built in their magefiles, there's an example in this plugin with the processor.
• Common asset management for plugins is centralized. No more copying and pasting configuration for the editor, golangci lint, github workflows, ...

pluginmage

All logic is bundled to this package which is the one we can move to the public package in the mattermost server for distribution.

$ mage
Targets:
  build:additionalBinaries    builds all additional binaries if set up by the plugin developers
  build:all                   builds both server, additional binaries, and webapp
  build:bundle                creates a distributable bundle of the plugin
  build:server                Build builds the server if it exists
  build:webapp                Build builds the webapp if it exists
  deploy:upload               builds and installs the plugin to a server
  dummy                       prints a hello message and plugin info
  pluginctl:deploy            uploads and enables a plugin via the Client4 API
  pluginctl:disable           disables a plugin via the Client4 API
  pluginctl:enable            enables a plugin via the Client4 API
  pluginctl:reset             disables and re-enables a plugin via the Client4 API
  webapp:dependencies         installs webapp dependencies using npm
  webapp:watch                builds and watches the webapp for changes, rebuilding automatically

Check the included README.md in the package.

Requires mattermost/actions-workflows#53

Ticket Link

Screenshots

--

Release Note

Adds new package with plugin tooling

[github-actions]

⚠️ One or more flaky tests detected ⚠️

• Failing job: github.com/mattermost/mattermost:Postgres with binary parameters
• Double check your code to ensure you haven't introduced a flaky test.
• If this seems to be unrelated to your changes, submit a separate pull request to skip the flaky tests (e.g. 23360) and file JIRA ticket (e.g. MM-52743) for later investigation.

Test	Retries
Postgres with binary parameters (Results)
com/mattermost/mattermost/server/v8/enterprise/message_export.TestRunExportJobE2EByType/using_dedicated_export_filestore/actiance_e2e_3_-_test_create,_update,_delete_xml_fields	1
com/mattermost/mattermost/server/v8/enterprise/message_export.TestRunExportJobE2EByType/using_dedicated_export_filestore	1
com/mattermost/mattermost/server/v8/enterprise/message_export.TestRunExportJobE2EByType	1

[davidkrauser]

question: If I don't like the defaults here for my use case (maybe I need to target a different platform or I need to enable CGO), how can I make changes? Previously, this configuration lived in each separate repository and the configuration could be modified directly. Now it lives in a unified repository that I may not have access to.

Would I need to fork the entire monorepo, make changes, and point to that? Or is there a simpler way to handle that scenario?

[fmartingr]

The idea of this is implement the basic functionality and then keep migrating plugins adopting and improving the toolkit. For example, we already support building additional binaries (coming from the legal-hold plugin which requires the processor to be built alongside the plugin) so things could be added as we work with it.

Checking the code I see that I'm handling the CGO in two different places. If I just remove the line you mention the defaults of the build configuration will allow GCO to be enabled if the env var CGO_ENABLED is set.

Do you have an example plugin where this is happening or more environment variables are required?

[davidkrauser]

The idea of this is implement the basic functionality [...]

That makes sense. Though when real users start pulling this in to build plugins, I'm worried that it won't be configurable enough to meet their needs. Should we have some consistent way to "configure" common aspects of the build that could be different?

Another example: targeting a different platform or architecture. From what I understand, we only build Linux binaries with this implementation (unless in developer mode).

[fmartingr]

Closing in favor of https://github.com/mattermost/pluginctl