Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 10 Next »

This document sketches out a greenlight proposal for Q4 2024 to improve the developer toolkit and accelerate efforts by Deployment Engineering in supporting our customers.

Centralize plugin build tooling

Efforts to ship the Legal Hold plugin alongside Mattermost v10 were held up by missing build tooling. Today, the Makefile and build/ infrastructure is copied from repo to repo, often getting out of date relative to the source of truth in https://github.com/mattermost/mattermost-plugin-starter-template

To solve this, let’s write all build tooling in Go (some already is) and host it in a build package as part of the public module in the monorepo. As part of this, we’ll switch to https://magefile.org/, but preserve a subset of the build interface in a Makefile to avoid CI breakage. (Running unsupported commands should teach users how to use Mage.)

Task List (~6 weeks)

  • Evaluate and prototype Mage in the starter template (1 week)

  • Centralize build tooling in the public module and upgrade starter template to match (1 week)

  • Upgrade demo plugin with these changes (2 days)

  • Upgrade supported plugins inside the Mattermost organization to use the new tooling (3 weeks)

    • Upgrading the build tooling will bring in a new version of the server and other supporting code, and might require tangential changes from any breaking changes in the API.

  • Document steps to convert a repository to adopt the new build format (2 days)

  • Document steps to upgrade a repository’s dependence on the public module (1 day)

Support Primary vs. Secondary Post Actions

When plugins gained the ability to add post menu actions, the drop down quickly became cluttered between primary actions and actions registered by plugins. This led to burying all plugin actions behind a secondary menu:

Unfortunately, this limitation stymies efforts by Deployment Engineering to give customers genuinely new primary actions. A similar change occurred in the past with the app bar vs. the channel header, and we should follow suit by restoring plugins' ability to register primary vs secondary post actions.

Task List (~3 weeks)

  • Introduce API to register primary post actions (1 week)

  • Update demo plugin to use both post actions (2 days)

  • Update e2e tests to ensure coverage of the new registration points (8 days)

Expand starter template

New efforts initiated by Deployment Engineering are stymied by a fairly bare bones starter template: just enough code to kickstart a server and webapp component in a plugin. Let’s expand the starter template with enough substance to accelerate new efforts, including:

  • A database store, interface, timerlayer generators, and support for migrations

  • A working Prometheus metrics endpoint, already tied into the database store and ready for extension.

  • The new “reattached” testing framework that accelerates unit testing with a minimum of mocking. (See MS Teams Plugin).

  • Playwright e2e tests framework, including CI integration. (See AI Plugin and Calls Plugin)

As part of these changes, let’s evaluate what to include directly in the starter template, and what to put in the public monorepo to reduce copy/paste requirements (e.g. generators for the database store /might/ make more sense centralized.)

Task List (~6 weeks)

  • Add database access to starter template (1 week)

  • Add metrics to starter template (1 weeks)

  • Productize and add “reattached” testing framework to starter template (2 weeks)

  • Add e2e tests to starter template (1 week)

  • Update demo plugin with latest starter template (1 week)

  • Document – inside the starter template – how to both use each of these extensions, and also how to remove them if unneeded. (1 day)

Review and polish API, Hooks, Wrapper & Utilities

Deployment engineering has run into various requirements that would ideally be fulfilled by a plugin hook, but wasn’t yet implemented in core (and thus not deployed to customers). Similarly, there are Plugin API gaps that create security review hurdles or add complexity to rapid plugin development. Let’s review and address these holistically.

Task List (~6 weeks)

  • Review existing plugin API and hooks for obvious gaps. (1 week)

    • GetUsersByIDs

  • Extend plugin API and hooks after review (2 weeks)

  • Expose authenticated user id in the plugin context, deprecating the Mattermost-User-Id header. (3 days)

  • Ensure plugin API wrapper has 100% coverage for plugin API. (1 week)

    • Build a tool to ensure 100% coverage going forward?

  • Extend plugin jobs framework to simplifying running jobs only on the job server, and at a specific time of day. (1 week)

Other Ideas

  • Common UI components: button, checkbox…

  • Single “mattermost-webapp” or “plugin-api” package import to rule them all

  • Common eslint configs / golangci configs?

    • Can we avoid plugin-specific configs and just force all plugins to “look the same”

    • Can we check these configs when the public submodule is updated to enforce they stay in sync? (Requires manual step, but “better” than auto-generating, having to .gitignore, works out of the box with editors, etc.)

  • Post menu pluggable section, deprecate to allow for accessibility

    • filtering, string <> localization

  • Rely on dependabot to automate updates of the public module and in turn help spur unified tooling across all the plugin repositories.

  • Review webpp plugin API for completeness

  • Adopt logrus-style conventions (hopefully using mlog).

    • Add helpers like WithUser([string | model.User]) to standardize logging keys like user_id

  • Formalize Redux package for use by plugins

    • Supported set of selectors

    • POJO actions (no thunks)

  • No labels