Development of External Plugins

In the following you will find a

  • description for the process for external plugin development;
  • quality gates that help you to write plugins of high quality;
  • useful links for plugin development

You will benefit from your plugin being included in the plugin center and from the code review of our team.

Process for external Plugin Development


1. Reach out to us via E-Mail

If you decide to write a plugin that is going to be published in our plugin center, please feel free to send an email to the SCM-Manager Team.

2. Fork of Plugin Repository

In the next step our team will create a fork of the plugin repository. Please note that you will not have writing permissions on the forked repository.

3. Code Review

The SCM-Manager Team will conduct a code review of the forked repository to make sure the code meets the needed requirements. Once the code review is approved, we will reach out to you again.

4. Implementation Build Process

After the Code Review is completed, we enable automatic build pipelines for your plugin.

5. Updates via Pull Requests

If you would like to adapt or update the plugin, feel free to send a pull request to the SCM-Manager team. We will review the pull request and merge it into the plugin.

Quality Gates

We are continuously trying to improve the SCM-Manager and offering all users a tool that is easy and comfortable to use. For a better development experience, we have a few recommendations for you:

Must-have requirements

The plugin requires a minimal documentation which consists of the plugin name and a short description. The plugin must support automatic build processes. That means the plugin must be automatically compilable. Please avoid using makefiles or manual compiling processes.
Please also make sure your plugin is published under the open source MIT license. Please note: “Closed source” plugins are also possible but no “binary-only”. We need the source code of the plugin.


We recommend you

  • to internationalize and translate your own plugin with i18n
  • to make outgoing network requests via the AdvancedHttpClient
  • and to use the internal store API for persistence. Saving data directly on the filesystem is considered to be bad practice.

Nice to have

We would really appreciate it if you use SCM-Manager-UI-Components to make the design and appearance consistent. If you write tests of the plugin it will help us to ensure high quality standards. It would be great if the plugin meets requirements for digital accessibility. A documentation on would help to let other users know what the plugin is about and how to use it.

No Gos

Please avoid writing plugins that download files or enable access to the user’s disk. It is not possible to implement such plugins into the SCM-Manager due to data privacy restrictions.

Useful Links for Plugin Development

The SCM-Manager documentation supports you with administration and usage of the SCM-Manager.

The section Plugin Development will help you to Create a Plugin. You can also find a Template for Plugin Development which helps you getting started.

1 Like

The SCM-Manager does not provide any kind of backup. Does this means that a plugin creating SVN dumps, git bundles or the Mercurial equivalents are not allowed?

Well, it depends how your implementation would look like. Actually we have written a plugin which will most likely be released today which does exactly this.

We named it Repository trash bin and it is kinda like a backup for deleted repositories before the repository is lost forever (similar to trash bin on Windows). In this plugin we create dumps (or specifically repo exports with all related SCMM metadata) and save these dumps inside a SCM-Manager blob store.

You can create new files or store any data, but it should be done using the SCM-Manager persistence api instead direct access on the file system. I hope this could clarify your concerns.

@eheimbuch thanks for the information. This sounds very good. Is it allowed to take this plugin as base for a “Backup” plugin? I’m thinking about something like a scheduled export of one or more repositories. Like a cron-job or something like that.

Sure, you can write your own plugin and use this as base.

The main logic for exports is here: BinManager
Here is an example for scheduled cron jobs: Cleanup Job

If you need any help or have questions regarding your implementation, just ask. In your case you may not even need a configuration or UI, so it should be pretty straight forward.

Thanks for the hints - they will guide me. I assume that I need some kind of UI because of the user setting the time where the job(s) have to start and additional the destination directory for the exports. I’ll have to check the code base to understand better what to do and how to do it.