Adding default settings for new repositories creation #46

Open tomdavidson opened 8 years ago

There is git-repo config that I am trying not to confuse. This issue is about configuring GitHub, GitLab, Bitbucket and not configuring git-repo. Maybe this is out of scope and fits in better with something such as Terraform.io

Problem: Repos will have a handful of settings, such as enabled services, branch protection, webhooks, merge types, mirroring, etc. Click though web gui introduces inconsistencies and other disadvantages.

If my org were to primarily use GitLab but mirror on GitHub then there are two namespaces to clear and two different configurations to deal with.

git all create would create whatever repos are configured, in my case, github and gitlab.

You have several ideas packed into one issue, and I actually had to reread several times your post to really understand it all ☺.

① Configuration file for "provider repos"

I'm not in favor of configuring remote repositories using extra config files. I chose to setup git-repo within the .gitconfig to keep things as small and convenient as possible, so I'd rather keep it that way.

It really is a design choice, I want git-repo to be stateless, using the git repository and the remote API as "data store". AFAICT, you can configure the services to have sensible defaults, and do some changes only on what's needed.

Though, nothing would prevent you from doing a little script that would do just that, taking advantage of a feature such as explained below in ②.

② Configuration of settings for repositories

There, I do understand your frustration, and there might be a case for extending the API to setup the different remote repositories. Maybe a simple interface that accesses configuration options such as:

git hub config list
git hub config get <key>
git hub config set <key> <value>
git hub config <user/repo> list
git hub config <user/repo> get <key>
git hub config <user/repo> set <key> <value>

could be a good way to implement a feature to configure the repositories, which would be a single simple interface for all the supported services APIs.

③ Add a `git all …` command

I believe there a good idea here, but I'm not sure of which command line API to offer, and how would it be the smartest way to handle that.

I guess that would be a long term feature that will help unify all the repository services as it's definitely non-trivial to do.

Thanks for the quick and detailed reply.

I would like to declare the configuration of my "provider repos" in code and by configuration rather than scripts. I do see such a feature as differnt than what git-repo currently does and understand if the functionality just does not fit. Would you characterized git-repo as more of a gitflow tool ( other than create )?

Currently, git-repos has hub|bit|lab create than takes one parameter - name. The proposed idea would provide the exact same functionality but would also have create accept many more parameters read from a file that is managed by git. Using git config's files vs some other file is great - for all the reasons provided and then some. Where does not matter as much as being in human readable file that is managed by git. There would be more parameters in the git-repo config but it would not be a dramatic change and would still be stateless.

A simplistic hypothetical:

uses the default namespace to configure both gitlab and github repos with: squash commits: protected master, public viability, and description.
configures the gitlab repo to mirror github.
github is not the development space, so its branching, issues and wiki are disabled.

[gitrepo "default"]
   allow_push_master = none
   merge_style = squash
   visibility = public
   description = this is a super awesome project that will solve all of your problems

[gitrepo "myprecious"]
    type = gitlab
    token = YourSuperPrivateKey
    fqdn = gitlab.example.org
    mirror_pull = github
    mirror_push = github

[gitrepo "github"]
    token = YourOtherVerySecretKey
    allow_push_branches = none
    allow_issues = none
    allow_wiki = none

With the addition of all the same command flow could be kept in place git hub create or git lab create and to do both (all that is in the config file) at the same time git all create. I agree, all might be slick, even without the other configuration - git all create orgname/reponame.

Lastly, once create supports more than the repo name, an update command would be nice = git all update. Rather than changing create maybe relying on update would be acceptable - git all create org/repo && git all update.

Sorry for taking long to get back to you.

Overall I believe this is a great feature to add, but it's not an obvious easy feature, and to be honest it's not in the ballpark for the next few releases (except if you implement it and push a PR!).

That being said, I believe there should be four feature requests, the first two that are almost trivial to implement, the third one would be quite a headache, and the last one should be done another way.

So I guess I'll have to split this issue in 4 new tickets!

① defaults for git-repo XXX create

For that feature I believe we should use something that makes it clear that we're talking about default values for create. So I guess I'd see more something like:

[gitrepo "myprecious"]
    type = gitlab
    token = YourSuperPrivateKey
    fqdn = gitlab.example.org
    create_repo_visibility = public
    create_repo_description = Fubar
    create_repo_merge_style = squash
    …

② Implement default configuration values and inheritence

Once the former has been implemented, this new feature makes sense:

[gitrepo "default"]
   create_repo_allow_push_master = none
   create_repo_merge_style = squash
   create_repo_visibility = public
   create_repo_description = this is a super awesome project that will solve all of your problems

and shouldn't be hard to implement, as configuration is being checked in those places:

③ implement "binding" between repository services

that one is a tougher one. I guess that your all service could be considered as a new gitrepo "all" section in the configuration, that would be configured with the mirror_* actions you're suggesting, something like:

[gitrepo "all"]
  mirror_create = github,gitlab,bitbucket
  mirror_gist = github,gitlab
  mirror_delete = github
  mirror_request = github

I'm not sure about the mirror_push and mirror_pull options, because that's to handle that use case that we got a all remote.

My only issue with that feature, is that it's a bit too meta, and implementing this might complexify the code base a bit too much, the tests will be a headache. So I'd rather keep that feature on the side once we got more lower level features implemented first.

④ changing the settings

About your update command idea, I'm not really for that. Firstly because I believe that having defaults for git XXX create is a good idea, and secondly becuase I'd rather see a settings command (with get/set) that would make it easy to change a repository's configuration:

git XXX config user/repo ls
git XXX config user/repo get key
git XXX config user/repo set key value

guyzmo / git-repo