Operator Skeleton Generators

[kensipe]

What this PR does / why we need it:

This PR provides skeleton generation for operator developers with the following capabilities.

Previously implemented but likely modified.
kudo package new foo -> creates a new operator from a relative location to the command. The default is to create an "operator" folder with operator and params files for an operator named foo.
kudo package new -i foo -> goes into interactive mode to create an operator, allowing for user input to the creation of the operator metadata.

This PR provides:

• kudo package add maintainer which adds maintainers to the operator
• kudo package add task which adds tasks and creates resources. It also guides the creation of pipe tasks.
• kudo package add plan which adds plans, phases, steps and tasks to the operator.
• kudo package add parameter which adds params to the params.yaml file.

Fixes #1087
Fixes #1081
Fixes #1083
Fixes #1084

[kensipe]

needs testing but otherwise good to go!

[alenkacz]

I watched the video for now https://drive.google.com/open?id=1R5flVq_rHBv3KipwqWOVDsISegmsLTsB I need to think about the feel of creating tree structure like plans/phases/tasks from CLI because it felt a bit hard to follow... I like that it tells you what are the options but other than that I find working directly with YAML a bit better.

[zen-dog]

I watched the video for now https://drive.google.com/open?id=1R5flVq_rHBv3KipwqWOVDsISegmsLTsB

First of all, nice video! 👏 I wish we would make more videos like this and post them on our blog. However, you could see that a purely CLI tool for generating nested plan/phase/step/task structures has limited usefulness - if I wouldn't know the underlying structure I would be lost there.

Questions:

• how do we ensure that the generator and the package structure don't drift apart? I mean things like overall structure, available task kinds, fields names, available field values etc.
• I saw that you're using custom validators for field values - is it worth revisiting the scheme-discussion?

[kensipe]

when we get this landed... I plan to have a more polished video and will push it to our youtube chan.

Regarding questions
re: how do we ensure that the generator and the package structure don't drift apart - like we do for any other feature. I don't think this is a reason to hold it back... there are tests in place which will help.

I'm not sure what custom validators for fields you are referring to :( scheme discussion welcomed but seems separate from this PR.

[gerred]

stylistic, mind adding whitespace between each } and next statement?

[gerred]

approval with some stylistic nits, overall looks good. does promptui include a default selection when confirming? i.e. (Y/n) or (y/N). I didn't see it in godoc and haven't tested.

[gerred]

oh, @kensipe, can you also add a flag to auto-confirm (or skip confirmation) so this can be used in CI/CD or other automated environments? Then someone could use it with atomist, or wrap it, etc.

[gerred]

@kensipe please open a tracking issue and link this PR as well as a checkbox for docs

[ANeumann82]

I wouldn't mind having this file split into more than one, but that's just a nit.