Promote ECK 2.16 branch to current

[naemono]

No description provided.

[github-actions]

A documentation preview will be available soon.

• 🔨 Buildkite builds
• 📚 HTML diff
• 📙 Preview page

Request a new doc build by commenting

• Rebuild this PR: run docs-build
• Rebuild this PR and all Elastic docs: run docs-build rebuild

_{run docs-build is much faster than run docs-build rebuild. A rebuild should only be needed in rare situations.}

_{If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here.}

[naemono]

INFO:build_docs:  /tmp/docsbuild/target_repo/html/en/cloud-on-k8s/2.9/k8s-eck-permissions.html contains broken links to:
--
  | INFO:build_docs:   - en/cloud-on-k8s/current/k8s-volume-claim-templates.html#k8s_updating_the_volume_claim_settings

🚨 Error: The command exited with status 255
--
  | user command error: exit status 255

@elastic/docs-repo-owners ^^ Is the above INFO message the cause of these failures? Or something else beyond my/our control? If so, why didn't we see this in #3139 ?

[colleenmcginnis]

👋 @naemono it looks like the problem is that:

• This new ID (resolves to k8s-volume-claim-templates-update) was added to the 2.16 branch in (Doc+) quickstart+KB cloud-on-k8s#8128.
• In previous versions, there was no ID specified so it was generating an ID (k8s_updating_the_volume_claim_settings).

I'm not too familiar with the cloud repo so @kilfoyle is probably the best person to decide which solution makes most sense, but it might involve:

• Updating the links in line 64 and line 72 to use the new ID.
• Backport those changes all the way back to 1.7.

[naemono]

👋 @naemono it looks like the problem is that:

• This new ID (resolves to k8s-volume-claim-templates-update) was added to the 2.16 branch in (Doc+) quickstart+KB cloud-on-k8s#8128.
• In previous versions, there was no ID specified so it was generating an ID (k8s_updating_the_volume_claim_settings).

I'm not too familiar with the cloud repo so @kilfoyle is probably the best person to decide which solution makes most sense, but it might involve:

• Updating the links in line 64 and line 72 to use the new ID.
• Backport those changes all the way back to 1.7.

Thanks for helping me understand what the issue is @colleenmcginnis . I'm confused by something though, if I look at the 2.15 branch, the link works. Why is the docs build process trying to use an id that only exists in the 2.16 branch in the 2.15 docs (and all previous branches as well)?

[colleenmcginnis]

Yea this is a confusing one. I think this is happening because line 64 and line 72 use hard-coded links to current in version 2.15 (and earlier), which is fine as long as 2.15 is the current version. BUT in this PR you are changing the current version to 2.16 so now those hard-coded links in 2.15 (and earlier) are trying to link to a page/section that doesn't exist in the new current (i.e. 2.16). 😵‍💫

[naemono]

Yea this is a confusing one. I think this is happening because line 64 and line 72 use hard-coded links to current in version 2.15 (and earlier), which is fine as long as 2.15 is the current version. BUT in this PR you are changing the current version to 2.16 so now those hard-coded links in 2.15 (and earlier) are trying to link to a page/section that doesn't exist in the new current (i.e. 2.16). 😵‍💫

OIC now... thanks a ton for that explanation. That helps me think through the correct way to fix this.

[colleenmcginnis]

The build made it through the link checking stage. If the check passes after the build is complete, feel free to merge!