dedupe

[davidcheung]

#134

• Should the created projects be checked into github automatically? (Y/n): y
• What’s the root of the github org to create repositories in? : github.com/my-org/
• Github Personal Access Token with access to the above organization : ABCD1234

#127

• Dedupe based on elimination(passed context and remove by key)

#135

• creating ~/.zero/credentials.yml
• reading ~/.zero/credentials.yml
• writing basic project config to ~/.zero/credentials.yml

Outstanding

• per module ask for directory name to use [backend/infrastructure/frontned]
• tests for any the prompts

[bmonkman]

Based on @cjhawkins 's PR regarding github it seems like we may need to switch around what we ask for here since we need to know if it's a personal repo or organizational, but we can handle that in another PR.

[bmonkman]

Is there a reason for these to be pointers to structs instead of just structs?

[bmonkman]

Also can we call this something more specific? Credentials and ProjectCredentials?

[davidcheung]

yeah, I need to persist the changes I make to the Project, the map[string]Project doesn't get the updated value otherwise

[bmonkman]

Only because Save is a pointer receiver. It could also be called like config.Save(projects) instead of projects.Save() There are a few things in this PR which look like they are structured in an OOP way which is not how things are typically done in Go.

[bmonkman]

Nice tests!

[bmonkman]

These should really be testing the API of the package rather than the internals. By calling a function like ReadOrCreateUserCredentialsFile it means that function now has to be exported, and I would think the only exported functions would be LoadUserCredentials and Save

[davidcheung]

Make sense, should I create another file for tests like this under the config package? so I can keep them private and still test them?

[bmonkman]

Maybe, though the general practice is try to make your tests in the _test package, then test the exported stuff and not the internals so that your test is coupled to the "API" which should be stable and not the internals which could change. And if you get to the point where the "API" is masking a massive amount of code, try to split it up into smaller packages which can be easily tested in isolation.