Implementing a new hoster

Steps how to implement support for backing up a new source code hoster, using the implementation for Bitbucket as an example.


In the ScmBackup project, create a new subfolder in the “Hosters” folder and name it like the hoster you are implementing, e.g. Bitbucket.

Inside the folder, create the classes listed below.


SCM Backup uses naming conventions to put everything together, so make sure that:

  • all classes have exactly the same prefix

  • the part after the prefix is exactly like in the examples below


To see examples, take a look at:


  • Example class name: BitbucketHoster

  • Must implement IHoster


Validates all config sources for that hoster.

  • Example class name: BitbucketConfigSourceValidator

  • Must inherit from ConfigSourceValidatorBase, which implements IConfigSourceValidator and contains “default” rules which apply to all hosters

  • Tests: Create a new class in ScmBackup.Tests.Hosters which inherits from IConfigSourceValidatorTests


  • Example class name: BitbucketApi

  • Must implement IHosterApi

  • Should call the hoster’s API and return a list of repository metadata for the current user or organization

  • Tests: Create a new class in ScmBackup.Tests.Integration.Hosters which inherits from IHosterApiTests


  • Example class name: BitbucketBackup

  • Must inherit from BackupBase, which implements IBackup and creates the actual backups by cloning the repositories.

  • Tests: Create a new class in ScmBackup.Tests.Integration.Hosters which inherits from IBackupTests


When a hoster supports multiple SCMs, you want to test backups with all of them, so you should create a separate test class for each SCM.

An example for this is Bitbucket, which supports Git and Mercurial, so there are BitbucketBackupGitTests and BitbucketBackupMercurialTests.

More about the tests

The base classes for the tests (IConfigSourceValidatorTests, IHosterApiTests, IBackupTests) contain all the tests and a few properties, some of them abstract or virtual.

The child classes just need to inherit from the respective base class and fill the properties (for repo URLs, commit IDs etc.).

So the same tests are executed for each IConfigSourceValidator, IHosterApi and IBackup implementation (please see also How to run the integration tests).


For special cases, which only apply to a certain implementation, you can create additional tests directly in the child class instead of the base classes.

One example for this is the Github API. There’s a special quirk which only occurs in the Github API.

Because of this, we have a special integration test for this, directly in the GithubApiTests class, so it’s only executed there, and not for all IHosterApi implementations.


Add the hoster to the lists on the website’s front page, and on the Introduction page in this documentation.