Change:
<ins> --- title: Generating reference documentation for metrics content_type: task weight: 100 --- <!-- overview --> This page demonstrates the generation of metrics reference documentation ## {{% heading "prerequisites" %}} {{< include "prerequisites-ref-docs.md" >}} <!-- steps --> ## Cloning the Kubernetes repository The metric generation happens in the Kubernetes repository. To clone the repository, Change directories to where you want the clone to exist. Then, execute the following command: ```shell git clone https://www.github.com/kubernetes/kubernetes ``` This creates a `kubernetes` folder in your current working directory. ## Generate the metrics Inside the cloned Kubernetes repository, locate the `test/instrumentation/documentation` directory. The metrics documentation is generated in this directory. With each release, new metrics are added. After you run the metrics documentation generator script, copy the metrics documentation to the Kubernetes website and publish the updated metrics documentation. To generate the latest metrics, Make sure you are in the root of the cloned Kubernetes directory. Then, execute the following command: ```shell ./test/instrumentation/update-documentation.sh ``` To check for changes, execute: ```shell git status ``` The output is similar to ``` ./test/instrumentation/documentation/documentation.md ./test/instrumentation/documentation/documentation-list.yaml ``` ## Copy the generated metrics documentation file to the Kubernetes website repository 1. Set the Kubernetes website root environment variable Execute the following command to set the website root: ```shell export WEBSITE_ROOT=<path to website root> ``` 2. Copy operation Copy the generated metrics file to the Kubernetes website repository. ```shell cp ./test/instrumentation/documentation/documentation.md "${WEBSITE_ROOT}/content/en/docs/reference/instrumentation/metrics.md" ``` {{< note >}} If you get an error, check that you have permission to copy the file. You can use `chown` to change the file ownership back to your own user. {{< /note >}} ## Creating a pull request To create a pull request, Follow the instructions in [Opening a pull request](/docs/contribute/new-content/open-a-pr/) ## {{% heading "whatsnext" %}} * [Contribute-upstream](/docs/contribute/generate-ref-docs/contribute-upstream/) * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) </ins>

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Add a section to that explains how to keep the generated pages within up to date. Why is this needed docs generation code into . We can tweak that code and then rely upon it. We'd want (I'm reasonably sure) to document what needs to happen for each major release so that we can keep the reference document up to date. got close to doing what we need, so this issue is about staffing the work to take it that last stretch to being mergeable. Comments /sig instrumentation /sig release /lifecycle frozen /triage accepted /priority important-longterm
Hey well i understood from the issue that we need to write documentation for kubernetes/kubernetes For every file present in the pr ,is that right??? Well i have some experience in writing docs can work on this /assign
can you review/assist here?
We need to document how someone in the release docs team can use automation to update the pages within that are automatically generated. To work out which pages within are generated automatically generated, you can either: ask contributors (eg from SIG Instrumentation - wrote all the generator code so far as I know) look at each page within and see whether that page is marked as automatically generated. The outcome is likely to be a change to either one or two pages within So long as the change allows a contributor in release docs to understand what to do, we've done enough to close this issue.
already started the process u can check my pr to review that if possible , many pr's are expected to come ,I'm working on it and has reviewed some part of it
I'm happy for anyone to review that PR. To ask for feedback more widely, join the Kubernetes Slack workspace - (visit for an invitation) - and ask in
is a good starting point.
It would be nice to have the steps documented. I'll help with this