Consider adding crossdocs functionality to crossplane-cli

[hasheddan]

Currently, the API docs on crossplane.io are generated using crossdocs. However, this is a cumbersome process that makes it difficult for new contributors to regenerate API docs when they make changes that affect them. It is also not obvious or documented that the tool is how we generate our API docs, nor is it obvious when API docs need to be regenerated (addressed by https://github.com/crossplaneio/crossplane/issues/1166). Furthermore, there are a number of issues with crossdocs currently that cause broken links and poorly formatted documentation (ref: https://github.com/crossplaneio/crossplane/issues/1223).

Moving the crossdocs functionality to crossplane-cli is advantageous for the following reasons:

• Helps movement toward doing all code generation and crossplane operations with a single tool
• Adding generation to crossplane-cli is an opportunity for rewrite and fixing of existing bugs
• Makes it easier for stacks built outside of the crossplaneio org to have good documentation with minimal effort

[displague]

I like the idea of offering all Stack authoring commands from the crossplane-cli.

I feel that there is an awkward experience provided when kubectl is the base command for actions which have nothing to do with Kubernetes (this is already the case for the build, init, and publish commands). This is an observation unrelated to this issue and could be remedied by having the crossplane-cli installation include non kubectl commands. Doing so could complicate distribution if krew becomes the primary installation method.

I think https://github.com/crossplaneio/crossplane-tools might be a better home for crossdocs, but I still agree that the appropriate crossplane-cli subcommand should (Go) import or shell out to crossdocs to offer a complete kubectl crossplane stack build experience.

As an alternative, inclusion of crossdocs in the build process be could also be accomplished with a Makefile change.

[hasheddan]

Closing this as we are migrating to https://doc.crds.dev for provider documentation :+1: