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.
Basics
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.
Note
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
Note
To see examples, take a look at:
- their tests:
...ConfigSourceValidatorTestsin the unit tests...ApiTests/...BackupTestsin the integration tests
Hoster
Example class name:
BitbucketHosterMust implement
IHoster
ConfigSourceValidator
Validates all config sources for that hoster.
Example class name:
BitbucketConfigSourceValidatorMust inherit from
ConfigSourceValidatorBase, which implementsIConfigSourceValidatorand contains “default” rules which apply to all hostersTests: Create a new class in
ScmBackup.Tests.Hosterswhich inherits fromIConfigSourceValidatorTests
Api
Example class name:
BitbucketApiMust implement
IHosterApiShould 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.Hosterswhich inherits fromIHosterApiTests
Backup
Example class name:
BitbucketBackupMust inherit from
BackupBase, which implementsIBackupand creates the actual backups by cloning the repositories.Tests: Create a new class in
ScmBackup.Tests.Integration.Hosterswhich inherits fromIBackupTests
Note
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 was Bitbucket, which supported Git and Mercurial (until they dropped Mercurial in 2020). So today there are BitbucketBackupGitTests…but in the past, there also were 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).
Note
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.
Documentation
Add the hoster to the lists on the website’s front page, and on the Introduction page in this documentation.