Add gitops & metaphor repository names as flags for create

[alechp]

What is your feature idea?

Problem:

Gitops & metaphor repository names are hard-coded

Screenshot:

Solution:

• Add --gitopsRepoName flag
• Add --metaphorRepoName flag
• Keep "gitops" & "metaphor" as sane defaults

Impacted files:

There might be more, just what I found off initial search

• kubefirst/cmd/google/create.go

  Line 66 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/digitalocean/create.go

  Line 67 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/civo/create.go

  Line 61 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/k3s/create.go

  Line 67 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/akamai/create.go

  Line 61 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/vultr/create.go

  Line 68 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

• kubefirst/cmd/aws/create.go

  Line 90 in a47ff7f

  newRepositoryNames := []string{"gitops", "metaphor"}

Why is it needed?

Why:

• maintaining multiple gitops repos for different clouds/regions
• maintaining associated metaphor repos for different clouds/regions
• mitigating risk of deletion when working with deletes (eg. spinning up a gitops directory on my local github to test something and then stressing that cleanup commands could nuke something on organization's github if I'm not careful)

Is this missing feature preventing you from using kubefirst?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[alechp]

Started fork: https://github.com/alechp/kubefirst/tree/feat/repository-name-flags-for-digitalocean

---

Still failing here:

Happy to keep exploring. Pointers to save time would be nice

Inside gitShim/init.go I see Repositories[] being referenced & looped through to check whether the repositories exist:

Updated the newRepositories here:

Noticed that the success message has a hard-coded gitops/metaphor. Which makes sense, but don't think that would impact create

I am not setting the flag with Viper in flags.go, but from what I can tell that's not necessary...? Perhaps I'm wrong

I didn't define it in apiTypes.ClusterDefinition which might be the issue (not sure how this impacts gitShim, but maybe the check that throws is being done elsewhere):

[fharper]

Thanks for this feature suggestion @alechp. Could you split those in two issues please as they will need different work in different places. Mainly, the gitops one will require a lot more work since it's hardcoded in multiples places.

[alechp]

Hey @fharper went ahead and split it into 3 issues (three requirements to enable deploying more than one gitops cluster per github organization):

• Enable specifying custom gitops repository name via CLI flag #2210
• Enable specifying custom team names (currently defaults to: admins & developers) generated in a Github organization via CLI #2211
• Enable specifying custom metaphor repository name via CLI #2212

[fharper]

Thanks a lot, and sorry for the additional work 😅

Will close this one now.