Automate command output in docs

[valaparthvi]

/area documentation
/kind epic

What mistake did you find / what is missing in the documentation / what is the relevance of it?

1. Store the current output for all the commands in separate mdx files.
2. Write integration/unit tests comparing the real time output of a command with the one stored in the mdx files.
3. If the test fails, it means that we need to update the output in mdx files.
4. The tests will be run in the CI for every PR.

For reference - https://www.youtube.com/watch?v=AQDILnknTJ0&list=PLUJzERpatfsWYhMH0NOjSXemQh5Tu9g1W&index=32&t=3s (it is in french)

Acceptance Criteria

• Setup IBM or prow jobs for the doc tests to run on every PR. #6517
• Every command output should be put inside a docs-mdx/.mdx file.
• Command Reference
  • odo dev
  • odo init (Doc Automation: Command Reference: odo init #6442)
  • odo preference view
  • odo add binding
  • odo remove binding
  • Automate Doc output: odo create namespace command reference #6675
  • odo delete namespace Automate Doc: odo delete namespace, odo list namespace, and odo set namespace #6724
  • odo build-images
  • odo list
  • odo list namespace Automate Doc: odo delete namespace, odo list namespace, and odo set namespace #6724
  • odo list component
  • odo list binding
  • odo deploy
  • odo describe binding
  • odo describe component
  • odo logs
  • odo set namespace Automate Doc: odo delete namespace, odo list namespace, and odo set namespace #6724
  • odo registry
• User Guides
  • Quickstart (WIP)
  • Test Quickstart guides on Podman
  • Advanced Guide
  • Connecting to a service
  • Experimental Mode

Example PR: #6442

[rm3l]

Is this a bug? Or a feature? :-p

[valaparthvi]

LGTM. I agree there is a lot of repetitive data, but since the Devfiles are quite different, it might be hard to factorize, IMO. Not an expert with MDX / JSX stuff, but there might be some room for reusability. So I am not sure it would be worth spending time right now trying to optimize this.

However, this makes me think of 2 things:

• Based on a recent discussion, maybe we could use each of those Devfiles as input in E2E tests, and import them as is in these docs. This way, we would be able to test them as well. And for line highlighting in the Docs, I can imagine some generic MDX Component accepting the path to the Devfile along with line numbers as input properties, so as to keep highlighting the relevant lines.

• These Advanced Guides could be simplified further now that we support parsing multi-document YAML in a single K8s component (Add support for parsing multiple k8s definition in a single Devfile K8s component #6372)

But that's another story that can be handled in separate PRs.

#6388 (review)

[rm3l]

As discussed, this low-priority item (from the 2023Q1 goals) has been moved back into the backlog. We should break this down into several small issues.

[github-actions]

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[rm3l]

/reopen
/remove-lifecycle stale
/remove-lifecycle rotten
/lifecycle frozen

[openshift-ci]

@rm3l: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle stale
/remove-lifecycle rotten
/lifecycle frozen

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 kubernetes/test-infra repository.