Plugin Manager Workflow Overview

The Plugin Manager (PM) Workflow described in Deployment overview requires plugin vendors to provide a plugin tarball downloadable from an URL. A metadata file containing said URL, name, version, etc. must also be created.

These files must be provided separately for each of the plugin build environments. An environment is the combinataion of operating system, version and hardware for example Debian/11/aarch64 or Flatpak/18.08/x86_64. It is easiest to configure a Continuous Integration (CI) setup for every build which:

Creates a tarball according to the specifications.
Uploads the tarball to a public site where it can be downloaded by the user.
Creates a metadata (xml) file according to the specifications containing correct tarball download URL and other plugin data.

Most plugins use one of the templates below to establish the Plugin Manager system:

Testplugin workflow is the most commonly used, partly because it has been around for awhile (recently updated and maintained). Typical settings for plugin and maintenance are located conveniently in the CMakeLists.txt fiie.

Shipdriver workflow is an updated variant, with some new functionality and a lot of simplifications.

Both frameworks use the same free opensource cloud services:

Github for plugin source repository
Cloudsmith for public storage of binary artifacts, notably tarballs, metadata and packages.
CircleCI, Appveyor, Drone.io and Github Actions to build (not all builders are used everywhere).
Travis.com to build, fading due to canceled free open-source options.

The setup of these services is also very similar, but there are differences. For a good conceptual graphic see Deployment overview

For Prerequisites see Prerequisite Overview and Prerequisite Services