Release-branch deploys should be production quality

[chalin]

Problem: currently, release-branch deploys are not "production quality". For example visit https://v1-24.docs.kubernetes.io/docs/home/ and view the page source. You'll see that the page source:

• Isn't minified
• Assets aren't finger printed -- e.g.:

  <link href="/scss/main.css" rel="stylesheet">
  <script src="/js/script.js"></script>

But release-branch deploys are officially supported documentation, and should be minified and assets finger printed (to avoid caching issues when assets are updated). The only thing that we don't want, as far as I understand, is for these deploys to be indexed. Is that correct @sftim?

Proposed Solution: recognized the officially supported release-branch deploys as "production" deploys, but with indexing turned off.

/cc @nate-double-u

[bishal7679]

/triage accepted

[sftim]

/area web-development
/priority backlog

Minifying assets for older docs sounds useful. However, there are other issues I'd prefer us to prioritize - for example, #23518

[chalin]

You're right @sftim, when seen in that context. Let me offer a more complete formulation (since I forgot to include the full context in this issue -- analytics migration -- taking it as implicit).

[chalin]

@sftim @nate-double-u - Ok, here's a more complete (hopefully better) picture of the situation as I see it.

When the website is built in production mode, we get the following by default from Hugo/Docsy:

1. Site indexing is permitted
2. Analytics is enabled
3. Artifacts are minified
4. Assets are finger printed

We want:

• All of the above features for the main deploy, and
• All except (1) for release-branch deploys

PR #36334 proposes to:

• Build release-branch deploys in production mode and
• Selectively disable (1) based on the value of the config paramdeprecated set to false for release-branches

This seems like an approach that is more compatible with Hugo/Docsy, and would require less code customization, as compared to continuing to build release-branches in non-production mode and then selectively turning on three features (2 to 4).

Hopefully this makes the benefits of #36334 clearer.

Thoughts?

[chalin]

@reylejano - during the 01/10 SIG docs meeting we discussed this issue among others. It's the previous comment in particular that I'd like your feedback on. Thanks! /cc @a-mccarthy @nate-double-u

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[chalin]

I still think that this is relevant. Waiting on feedback from #36333 (comment).

[sftim]

Minifying assets for older docs sounds useful. However, there are other issues I'd prefer us to prioritize - for example, #23518

This is still my opinion. However, we're also looking to revisit the approach for serving older docs. If we do that, I expect that this request gets delivered implicitly.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.