Trendz: add missing 1.15.0.6 and 1.15.1.1 patches, fix Kubernetes upgrade for 1.15+

[RomenKost]

Description

Adds the missing Trendz 1.15.0.6 and 1.15.1.1 patch releases and fixes the Kubernetes upgrade instructions for Trendz 1.15 and later.

Missing patch releases

• Release notes for 1.15.0.6 (Mar 25, 2026) and 1.15.1.1 (Apr 28, 2026).
• Both patches are added to the releases table and the upgrade instructions.
• The upgrade instructions now list every release, including earlier patches of the same version. Before, only the newest patch of each base version was shown, so adding 1.15.0.6 would have hidden 1.15.0.5.

Kubernetes upgrade for 1.15+

• The previous steps updated the image and applied the deployment, but the deployment never runs the database upgrade for 1.15+. The new steps stop Trendz, run a one-off trendz-upgrade Job with UPGRADE_TRENDZ=true, check its logs, delete it, and start Trendz again.
• Both trendz and trendz-python-executor images are updated.
• For patch releases, a note explains that upgrading from the same base version (for example, 1.16.0.x → 1.16.0.1) only needs the new images applied, without the job.
• The "Prepare" section now includes a database backup step.
• The steps for 1.14 and older (the .upgradeversion flag file) are unchanged apart from wording.

Type of change

• Shared include file (src/content/_includes/**)
• Component, layout, or styling change (src/components/**, src/styles/**)
• Version bump / release (src/data/versions.ts, src/models/upgrade-instructions.ts, src/models/releases-table.ts)

Affected products

Trendz only.

Checklist

• Base branch and labels follow Which branch and label
• pnpm check passes (Astro / TypeScript)
• pnpm lint:eslint passes
• pnpm lint:slugcheck passes
• pnpm lint:linkcheck passes locally
• No hardcoded versions — values come from src/data/versions.ts

[vvlladd28]

Review summary

Reviewed 5 changed files in Trendz: add missing 1.15.0.6 and 1.15.1.1 patches, fix Kubernetes upgrade for 1.15+. Left 2 comment(s) inline.

The Job manifest matches trendz-app-deployment.yml in trendz-k8s (ConfigMap names, keys, mount path, namespace). The main issue is that the new kubectl commands don't pass -n trendz, so scale/wait/logs/delete hit the default namespace (TrendzK8sJobSteps.astro:54). Spelling and grammar in the new release notes and steps look clean.

Additional findings

These observations are about existing code outside the PR's diff — spotted while reading surrounding context.

• src/content/docs/docs/trendz/installation/kubernetes.mdx:67 — The install page tells users to edit trendz-secret.yml, but trendz-k8s has no such file and Step 3 never applies it. The datasource URL, username and password actually live in trendz-app-db-config.yml (the ConfigMap the deployment, and now the upgrade Job, read via envFrom). Someone following this page edits a file that doesn't exist and deploys with the default postgres/postgres credentials.

---

This review was auto-generated. Findings may contain errors — please verify before applying changes.

[vvlladd28]

Every trendz-k8s resource lives in namespace trendz (the Job YAML hard-codes it too), but none of these commands pass -n trendz. Neither do kubectl wait … job/trendz-upgrade, kubectl logs job/trendz-upgrade, kubectl delete job trendz-upgrade or the final scale below. kubectl apply -f works because the manifests carry the namespace. The rest resolve against the current context, which is default for most users. They fail with NotFound, and the dangerous case is this first one: if scale --replicas=0 fails and the reader carries on, the upgrade Job migrates the DB while Trendz is still running.

Could you add -n trendz to each command, or add a kubectl config set-context --current --namespace=trendz step at the top? Also, depending on the kubectl version, kubectl wait --for=delete pod -l … can return no matching resources found when the pods are already gone. A short note that this is fine would save a confused reader.

[RomenKost]

Added: kubectl config set-context --current --namespace=trendz in Prepare section
Added: If the pods are already gone, kubectl wait may print no matching resources found. This is expected.

[vvlladd28]

The aside says "No upgrade job is needed", and the full job procedure renders right after it. Only the aside title ("Upgrading from 1.15.0.x") scopes it. A reader upgrading 1.15.0.x → 1.15.1.1 sees this note for the same target version and may skip the job they actually need. Could you end the aside with something like "Otherwise, follow the steps below." (or "…and skip the steps below") so it's explicit which path applies?

[RomenKost]

Added: "From any other version, follow the steps below."

[vvlladd28]

Re-review summary

Re-reviewed Trendz: add missing 1.15.0.6 and 1.15.1.1 patches, fix Kubernetes upgrade for 1.15+ — verified 2 finding(s) from previous review.

Status	Count
✅ Resolved	2
💬 Acknowledged	0

All previous findings have been addressed. The fix commit introduces no new issues.

Finding details

• ✅ src/components/upgrade-instructions/TrendzK8sJobSteps.astro:54 — kubectl commands ran without -n trendz and hit the default namespace — Fixed in code: the Prepare section, which renders once above every version, now sets trendz as the context's default namespace. A note now explains kubectl wait's no matching resources found.
• ✅ src/components/upgrade-instructions/TrendzUpgradeSteps.astro:317 — the "No upgrade job is needed" aside didn't say which path applies — Fixed in code: it now ends with "From any other version, follow the steps below."

---

This re-review was auto-generated. Findings may contain errors — please verify before applying changes.