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:
...ConfigSourceValidatorTests
in the unit tests...ApiTests
/...BackupTests
in the integration tests
Hoster¶
Example class name:
BitbucketHoster
Must implement
IHoster
ConfigSourceValidator¶
Validates all config sources for that hoster.
Example class name:
BitbucketConfigSourceValidator
Must inherit from
ConfigSourceValidatorBase
, which implementsIConfigSourceValidator
and contains “default” rules which apply to all hostersTests: Create a new class in
ScmBackup.Tests.Hosters
which inherits fromIConfigSourceValidatorTests
Api¶
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 fromIHosterApiTests
Backup¶
Example class name:
BitbucketBackup
Must inherit from
BackupBase
, which implementsIBackup
and creates the actual backups by cloning the repositories.Tests: Create a new class in
ScmBackup.Tests.Integration.Hosters
which 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 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).
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.