create new cli command for kubefirst create github-cluster

[johndietz]

No description provided.

[6za]

Define the CLI require flags for the command, to ensure we know from get-go what is needed from github and how to differentiate from a gitlab installation.

[6za]

We start as 2 different create journeys, on a later ticket we have a "wrapper" create that use flags to select the proper installation strategy.

[6za]

Reviewing a bit the logic we use:

• We usually add parameters at the init command, not the create one.
• Eventually we need to change init to capture configs needed to support github
• Update .kubefirst to support it
• When running create we check if the plan, match the execution command.

New create strategy, based on github.

• If all good, installation proceeds as desired.

[6za]

Based on this exploration:
https://github.com/kubefirst/kubefirst/blob/eedfe3ed34c13a64d06193a55d9d3dd51e9fb93d/cmd/createGithub.go

Questions:

• Does anything changes on setup of ArgoCD?
• How to improve Hand-off screen to support github/gitlab?

Different object, Object architecture, "Strategy pattern" or different pattern of reuse.

Assumptions:

• OIDC/SSO will be handled by spike: fusion auth for oidc feature parity with gitlab #157

[6za]

Exploring a bit how to integrate to github to try to automate github access.

[6za]

Github Actions needed:

• create repo
• Add ssh key?

do we create the keys, or the user does that

[6za]

How to get the github token?

• Viper: As part of viper, may makes some user uncomfortable, but possible. The issue is that to load it viper it needs to be passed to init to add it to the .kubefirst file.
• Init Parameter: For demo to pass the token from a parameter may be bad for laking it on demos, so eventually it end-up a environment variable to hide value on demos.
• ENV Vars: Env variables seems to be the way most APIs use it.

I would go with Env Variable as most projects does.

[6za]

Added on #223