fix(gen-apidocs): render ContainerStatus in Pod Markdown reference

[qiujiaro]

Fixes #467

Related:

• ContainerStatus not defined in Pod defn kubernetes/website#56427
• Fix ContainerStatus section in Pod API reference kubernetes/website#56463

Check closestTopLevelHome before skipping pattern-inlined definitions. This
allows ContainerStatus to be inlined into the Pod page while preserving the
existing behavior for definitions without a unique top-level owner.

A regression test covering the ContainerStatus -> PodStatus -> Pod reference
chain is included.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: qiujiaro / name: Jiarong Qiu (732a751)

[kubernetes-prow]

Welcome @qiujiaro!

It looks like this is your first PR to kubernetes-sigs/reference-docs 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/reference-docs has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: qiujiaro
Once this PR has been reviewed and has the lgtm label, please assign reylejano for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[qiujiaro]

/easycla

[Caesarsage]

Thanks for the PR.

changing inline-definition classification can affect other generated API pages. Did you confirm this @qiujiaro ?

[qiujiaro]

Thanks for the PR.

changing inline-definition classification can affect other generated API pages. Did you confirm this @qiujiaro ?

The generated changes are limited to these expected definition restorations #467 (comment) and did not find unrelated changes to other API pages.

[lavishpal]

can closestTopLevelHome(d) return a valid parent for all d.IsInlined definitions? if not, what cases are expected to have IsInlined == true but no top-level home?

[qiujiaro]

I checked this more carefully; my previous words need a little bit changes.

ClosestTopLevelHome(d) cannot return a valid parent for every d.IsInlined definition. The two properties come from independent mechanisms:

• IsInlined is assigned using naming conventions, such as ${resource}Spec, ${resource}Status, and ${resource}List.
• closestTopLevelHome follows the actual AppearsIn reference graph and returns only a unique reachable InToc definition. It returns nil when none is reachable or when the closest candidates are tied.

---

I found 2 expected cases where an IsInlined definition has no reachable InToc home:

1. *List definitions, such as PodList, DeploymentList, and ClusterRoleList. Their AppearsIn is commonly empty because they are not referenced as resource schema fields. They are already rendered through the naming-based parent Inline relationship and the explicit d.Name + "List" handling.
2. Spec/Status definitions whose parents are not InToc. These remain rendered as part of their parent’s standalone definition page.

For example, the reference TokenReviewSpec -> TokenReview exists, but TokenReview is not an InToc resource, so there is no "top-level home". It will still appear in the standalone definition page of TokenReview through the original TokenReview.Inline relationship.

Therefore, the d.IsInlined fallback is intentional. It preserves the existing naming-based handling when no unique top-level home exists, while allowing definitions such as ContainerStatus( ContainerStatus -> PodStatus -> Pod), to be assigned to the Pod page first.

[qiujiaro]

quick ping @lavishpal , just see if you have a chance to have a look