Background and motivation
Currently, collections can only be created from repositories that support the GitHub-API. The generator can not be used for repositories that are hosted on GitLab, BitBucket, etc. (further called providers)
Code-wise, it is already possible to implement new providers, by implementing the PackageMetadataProvider-protocol. I implemented a provider for GitLab and it went quite smooth. The command-line-parameter for auth-tokens is also already prepared for multiple providers. What is missing, is a method to define the provider for a host / for a repository.
Open questions
- Inside the json that contains the repository-urls of the packages is no information which provider has to be used for it. How do we want to add this information? A few possibilities I have in mind:
1.1. Declare the provider per host as parameter, like:gitlab:git.mycompany.com,bitbucket:bucket.mycompany.com. Contra: A bit of a hassle to add it everytime you re-generate the collection.
1.2. Request to an API-specific URL (like git.mycompany.com/api/v4/projects) to find out which one of them it is. Contra: Scales not very well. Bombarding hosts with unnecessary requests doesn't sound good.
1.3a. Add the provider in the input-JSON-file. For each package, it has to include the provider, like "provider": "github". Contra: Probably repeating the same information for many packages that are stored on the same host.
1.3b. Declare the mapping of a host to the provider inside the input-JSON-file as seperate dictionary. For each host, it has to include the provider, like
{ "git.mycompany.com": "gitlab", "github.com": "github" }
From those options, I prefer 1 and 3b. Are there better options available? What do you think?
- Should there be an implicit logic to choose the provider based on the URL, if it contains the name of a supported provider? (
github.comwould choose the GitHub-provider,gitlab.mycompany.comwould choose the GitLab provider and so on).