Mark EphemeralContainers as GA in 1.25

[verb]

This PR updates the website to reflect ephemeral containers graduating to GA.

Checklist before review:

• Merge Promote EphemeralContainers feature to GA kubernetes#111402
• Update imported docs to remove beta labels on API reference

[netlify]

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

Name	Link
🔨 Latest commit	3ad2a78
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/62eacbe804076a00083f473c

[sftim]

Some early feedback/

[verb]

@sftim There's more out of sync with api-reference than just ephemeral containers, so I think this must be updated all at once as part of the release process and I've only updated the section heading here.

Nothing else changed for ephemeral containers this release, so I think this is ready for review.

[sftim]

We update generated reference docs at release time.

I would make the change to api-ref-assets/config/fields.yaml in a separate PR. @feloy: are there docs for how folks should update that file?

[feloy]

We update generated reference docs at release time.

I would make the change to api-ref-assets/config/fields.yaml in a separate PR. @feloy: are there docs for how folks should update that file?

@sftim This section of the README tries to document the process: https://github.com/kubernetes/website/blob/main/README.md#building-the-api-reference-pages

Running make api-reference makes some tips on the changes necessary to the files, but there is still some work to document it better

[verb]

Just so I understand, why make api-ref-assets/config/fields.yaml changes in a separate PR? So the output is easier to review?

@feloy should I just run the api-reference update as part of the fields.yaml change in order to verify the fields.yaml change has the desired effect? Presumably it's not a problem if api-reference gets updated multiple times during the release process.

[feloy]

Just so I understand, why make api-ref-assets/config/fields.yaml changes in a separate PR? So the output is easier to review?

For the moment, we are used to create a single PR to update the fields.yaml/toc.yaml files and the generated Markdown pages, for example #29668

But the change done here about moving a field from Beta level to non-Beta level is difficult to catch afterwards, and for this reason I would prefer it is done in this specific PR, or you could create some issue for me to remember to do it as part of the global PR.

@feloy should I just run the api-reference update as part of the fields.yaml change in order to verify the fields.yaml change has the desired effect? Presumably it's not a problem if api-reference gets updated multiple times during the release process.

Yes, you would have to run the make api-reference command to generate the Markdown files that will be displayed in the website, to check the change is what you expect.

[feloy]

The change in fields.yaml is done in #35676

[reylejano]

/assign @sethmccombs
/cc @kcmartin

[reylejano]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: reylejano

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

The pull request process is described here

Needs approval from an approver in each of these files:

• content/en/OWNERS [reylejano]

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

[tengqm]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: d86f9aed8c01847fabec13c11ddc0bb06551894e