Jx: improve initial boot UX and allow folks to customise jx requirements before booting

[rawlingsj]

The UX for jx boot could do with being a little more intuitive.

My flow:

jx create cluster gke --skip-installation
jx boot # this clones locally the latest version of the jx boot config

The boot wizard it bombs out because the jx requirements default to private repos and the org I use is public.
I now need to go to the CLI docs on the website and figure out how to use my public github org (this isn't that easy either). I then change into the locally cloned boot config repo, update the desired fields and re-run jx boot.

It feels like we should be able to have a step / command that helps build up the initial requirements. There's already a flag for boot to specify an existing jx-requirements.yml but even then it's not obvious where to get an initial version of this so that folks can then customise.

Some suggestions on this thread in slack on how to get the initial default requirements and begin to customise before initially running boot - https://kubernetes.slack.com/archives/C9MBGQJRH/p1578505392064500

• add a jx boot --init flag that clones the boot config repo locally and nothing else
• add a jx create requirements or jx setup command, this starts a wizard to help generate a jx-requirements.yml

/area boot
/kind improvement

I don't use a paid github org which means I need to change the initial jx requirements to use public git repo settings.

[rawlingsj]

/kind enhancement

[MarckK]

Yes please!

I've been working on a walkthrough tutorial for starting with Jenkins X OSS for the first time. And because of this issue my workaround was to have users:

• create a cluster

• then clone the jx boot config repo

• edit jx-requirements.yml to set environmentGitPublic to true

• then run jx boot

The suggestions you've made to improve the UX are very good improvements to have.

[jstrachan]

FWIW we made those improvements in the jxl boot command: we create the git repository first then let folks configure git + modify secrets before running boot on the git repo

[jenkins-x-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

[rawlingsj]

/remove-lifecycle stale

[jenkins-x-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

[jenkins-x-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten

[jenkins-x-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

[jenkins-x-bot]

@jenkins-x-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.