chore(apps/gcp): release resource serving images

[dillon-zheng]

Summary

• release CI Dashboard and its job images at v2026.8.23-13-g6426db9
• release all GCP Cost Insight CronJobs at the matching published image

The tag was published by ee-apps release run 33030049791.

Validation

• yq eval for the changed manifests
• kubectl kustomize apps/gcp/ci-dashboard
• kubectl kustomize apps/gcp/cost-insight

Full apps validation was attempted; its kustomize/kubeconform phase could not run locally because standalone kustomize and kubeconform are not installed.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign dillon-zheng for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary
This PR updates the image tags for the GCP CI Dashboard and all GCP Cost Insight CronJobs to a new release version v2026.8.23-13-g6426db9. The approach is straightforward: replace the old image tags with the new one consistently across multiple Kubernetes manifests. The changes appear mechanical and consistent, with no obvious logic errors or regressions introduced.

---

Code Improvements

• File: apps/gcp/cost-insight/cronjobs.yaml (multiple lines)
  Issue: The same image tag is repeated for many containers. If in the future the image tag needs to be updated again, this will require multiple manual edits, risking inconsistencies.
  Suggestion: Consider parameterizing the image tag with a Kustomize variable or Helm value to centralize the version management. For example, in a kustomization.yaml:

  images:
    - name: ghcr.io/pingcap-qe/ee-apps/cost-insight-jobs
      newTag: v2026.8.23-13-g6426db9

  Then remove explicit tags from the cronjob manifests. This reduces duplication and errors in future releases.

---

Best Practices

• Documentation
  File: PR description and commit messages
  The PR description mentions that the full apps validation could not run locally due to missing kustomize and kubeconform. It would be better to document any CI validation steps explicitly or add instructions to install these tools for reproducibility and confidence in the release process.

• Testing Coverage
  There is no mention of automated tests verifying that CronJobs run correctly with the updated images. If possible, add a smoke test or integration test to confirm that the new container images deploy and run as expected.

• Style / Consistency
  The comment # renovate: datasource=docker depName=ghcr.io/pingcap-qe/ee-apps/ci-dashboard versioning=semver is present in release.yaml but not in cronjobs.yaml. If the latter is also managed by Renovate, consider adding analogous comments for consistency and automation support.

---

Summary of Suggestions

• Refactor image tag references to use a centralized parameter via Kustomize or Helm to reduce duplication and risk of inconsistencies.
• Document CI validation steps or prerequisites for local validation to improve reproducibility.
• Consider adding tests to verify the updated image tags in the cluster environment.
• Add Renovate metadata comments where applicable for automated dependency management.

These changes will improve maintainability, reduce human error during releases, and increase confidence in the deployment process.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary:
This PR updates the image tags for the ci-dashboard and all cost-insight cronjob containers to release newer versions of the images. The approach is straightforward: replacing the older tags with the latest published ones in the YAML manifests under apps/gcp. The changes are limited to image tags only and do not alter any other configuration. Overall, the PR is clean and low-risk, but there are some opportunities to improve maintainability and validation.

---

Code Improvements:

• Centralize image tag management:
  The cost-insight/cronjobs.yaml file updates the same image tag (cost-insight-jobs) in multiple places. This is error-prone and hard to maintain. Consider using a kustomize images transformer or Helm values to set the image tag in one place, reducing duplication and the chance of inconsistencies.
  File: apps/gcp/cost-insight/cronjobs.yaml
  Why: Avoid manual repetition of the same tag update in many container specs.
  Suggested approach:

  # kustomization.yaml example
  images:
    - name: ghcr.io/pingcap-qe/ee-apps/cost-insight-jobs
      newTag: v2026.8.23-15-g9699b7f

  Then remove explicit image tags from the pod specs.

• Improve validation instructions and automation:
  The PR description notes that kustomize and kubeconform could not run locally due to missing tools. Consider adding a script or GitHub Action step to automate manifest validation before merging. This ensures no regressions and improves confidence in releases.
  Why: Manual validation is error-prone and incomplete. Automated validation improves reliability.

---

Best Practices:

• Add or update comments to clarify tag updates:
  In apps/gcp/ci-dashboard/release.yaml, there is a comment for renovate automation on the image line but not for cost-insight/cronjobs.yaml. Adding a similar comment or documentation about how image versions are managed helps future contributors.
  File: apps/gcp/ci-dashboard/release.yaml line ~37
  Suggested addition:

  # renovate: datasource=docker depName=ghcr.io/pingcap-qe/ee-apps/cost-insight-jobs versioning=semver

• Testing coverage for image updates:
  The PR relies on kustomize output validation but does not mention any runtime or integration testing validation after updating images. Ideally, a smoke test or deployment verification should be included in CI to catch any image incompatibilities early.
  Why: Image tag bumps may introduce runtime changes impacting functionality.

---

Minor suggestions:

• Consistent imagePullPolicy:
  All containers use IfNotPresent which is fine for stable releases, but consider if Always is more appropriate for CI images during active development to avoid caching stale images. Confirm this matches your deployment strategy.

---

Overall:
This PR accomplishes its goal of updating image tags cleanly. The key improvement is to reduce duplication in image tag specification and improve automated validation to prevent human error and increase release confidence.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary
This PR updates image tags in the GCP apps manifests for the ci-dashboard and cost-insight cronjobs to newer release versions. The approach is straightforward: it bumps the container image tags for multiple Kubernetes workload definitions to a new version string. The changes are minimal and focused on version updates, with no structural or logic changes. Overall, the changes look consistent and correct for a release bump.

---

Code Improvements

• apps/gcp/cost-insight/cronjobs.yaml (lines ~32,146,212,298,377,468,548):
  The same image tag v2026.8.23-16-g91982bd is repeated multiple times across several containers. To reduce duplication and risk of inconsistency:

  • Consider using Kustomize image tags or a centralized image tag variable to manage this tag in one place. This improves maintainability and reduces errors during future updates.
    Example:

  images:
    - name: ghcr.io/pingcap-qe/ee-apps/cost-insight-jobs
      newTag: v2026.8.23-16-g91982bd

  Then refactor the cronjob manifests to reference this tag dynamically.

• apps/gcp/ci-dashboard/release.yaml (line 35):
  Same suggestion applies for the ci-dashboard image tag to avoid hardcoding tag in multiple places.

---

Best Practices

• Documentation / PR Description:
  The PR description is clear about what was updated and how validation was done. However, it would be helpful to include:

  • Confirmation that the new images were successfully pushed and tested in a staging environment.
  • Any relevant release notes or changelog references for these versions.
  • Details about the validation limitations (missing local kustomize and kubeconform tools) and whether CI pipelines ran these validations successfully.

• Testing coverage:
  The PR mentions local validation attempts but no mention of automated CI tests passing with these new images. Ensure the CI pipeline runs kustomize builds and schema validations with the updated images to catch any regressions.

---

No critical issues or bugs were detected, as this PR purely updates image tags in manifest files and does not change logic or application code. The recommendations focus on improving maintainability and ensuring robust validation.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary:
This PR updates the container image tags for the GCP CI Dashboard and all GCP Cost Insight CronJobs to new versions reflecting the latest release v2026.8.23-13-g6426db9 for the dashboard and v2026.8.23-17-g39f1765 for the cost insight jobs. The approach is straightforward, modifying image tags in Kubernetes manifests. The changes are mechanically consistent and follow the expected pattern for a release update. Overall, the PR is clean and focused, with no apparent errors in the diffs.

---

Code Improvements:

• apps/gcp/cost-insight/cronjobs.yaml (lines 32-556 approx):

  • The same image tag is repeated multiple times for different containers within the cronjobs manifest. This is prone to manual errors and makes future updates tedious.
  • Suggestion: Use Kubernetes manifest templating or kustomize image transformer features to centralize the image tag definition. For example, define an images section or use kustomization.yaml with images: field:

    images:
      - name: ghcr.io/pingcap-qe/ee-apps/cost-insight-jobs
        newTag: v2026.8.23-17-g39f1765

    This reduces duplication and simplifies future tag updates.

• apps/gcp/ci-dashboard/release.yaml (line 35):

  • Similar to above, if this manifest is part of a kustomize overlay, consider managing image tags via kustomize images: field rather than editing YAML directly.

---

Best Practices:

• Documentation:

  • The PR description is clear about the purpose and validation, but the manifests themselves lack comments about the version update or any context. Consider adding a brief comment near the image tag lines, e.g.,

    # Updated to release v2026.8.23-17-g39f1765 for cost insight jobs

    This helps future reviewers understand the reasoning behind the tag update.

• Testing Coverage:

  • The description mentions local validation attempts but notes missing tooling (kustomize and kubeconform). This is a potential risk.
  • Suggestion: Ensure the CI pipeline runs kustomize and kubeconform validation on these manifests to catch schema or formatting issues automatically before merging.

---

Minor Notes:

• The PR title and description mention “release resource serving images” which could be more descriptive, e.g., “chore(apps/gcp): update release image tags for ci-dashboard and cost-insight cronjobs.”
• No style or formatting issues detected in the YAML files.

---

Summary of actionable feedback:

• Use kustomize image transformers or centralized image tag management to avoid repeated manual tag updates across multiple container specs.
• Add comments near image tags explaining the reason for the update.
• Ensure CI runs full manifest validation with kustomize and kubeconform to prevent invalid manifests from being merged.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Summary
This PR updates the GCP CI Dashboard and Cost Insight CronJob images to new release tags and adds a new CronJob resource-serving manifest for resource-serving image materialization. The approach is straightforward, updating image tags and adding the new CronJob YAML with an embedded Python script to determine date ranges dynamically. The PR is mostly clean and clear but can be improved in error handling, maintainability, and validation.

---

Critical Issues

• Embedded Python Script Error Handling

  • File: apps/gcp/cost-insight/resource-serving-cronjob.yaml (lines ~30-70)
  • Issue: The embedded Python script raises a generic RuntimeError if no attribution date is available, but no fallback or alerting mechanism is in place. This might cause silent CronJob failures.
  • Suggestion: Improve error handling by logging or exiting with a clear error message. Consider adding retries or a fallback date range to prevent job failure from blocking downstream processes.

• No Image Tag Variables / Version Consistency

  • Files: apps/gcp/ci-dashboard/release.yaml, apps/gcp/cost-insight/cronjobs.yaml, apps/gcp/cost-insight/resource-serving-cronjob.yaml
  • Issue: Image tags are hardcoded and updated manually in multiple places, increasing the risk of inconsistencies or human error.
  • Suggestion: Use kustomize images field or helm templating to centralize image tag versioning for easier updates and consistency across manifests.

---

Code Improvements

• Refactor Embedded Python for Maintainability

  • File: resource-serving-cronjob.yaml (lines ~30-70)
  • Issue: Embedded multiline Python script inside shell script args is complex and hard to maintain/debug.
  • Suggestion: Move this logic into a separate script file included in the container image, or use a ConfigMap volume mount with the script. This improves readability and simplifies changes.

• Resource Requests and Limits

  • File: resource-serving-cronjob.yaml (lines ~75-79)
  • Issue: The resource requests/limits are quite high (2-4 CPU, 4-8Gi memory). This could cause scheduling issues or resource contention if multiple CronJobs run simultaneously.
  • Suggestion: Validate if these resource requests are necessary or can be optimized. Consider adding resource limits to other CronJobs if missing for consistency.

• CronJob Backoff Limit Set to 0

  • File: resource-serving-cronjob.yaml (line ~22)
  • Issue: backoffLimit: 0 means no retries on failure, which might cause missing data if the job fails transiently.
  • Suggestion: Evaluate if a small positive backoff limit (e.g., 1-3) is preferable to improve job resilience.

---

Best Practices

• Add Comments to Complex Sections

  • File: resource-serving-cronjob.yaml (lines ~30-70)
  • Issue: The embedded Python script has no comments explaining its purpose or logic.
  • Suggestion: Add descriptive comments to the script and the overall CronJob spec for maintainers.

• Testing / Validation

  • PR Description notes that kustomize and kubeconform could not run locally.
  • Suggestion: Add these tools to the local dev environment or CI pipeline to validate manifest correctness automatically. Consider adding automated tests or dry-run validations in the PR workflow.

• Naming Conventions Consistency

  • File: resource-serving-cronjob.yaml
  • Issue: The CronJob name ci-rs-resource-serving-native-refresh uses abbreviations (ci-rs), which might not be immediately clear.
  • Suggestion: Use more descriptive and consistent names, e.g., cost-insight-resource-serving-native-refresh, matching labels for clarity.

• Use of TimeZone Field

  • File: resource-serving-cronjob.yaml (line ~15)
  • Note: The use of timeZone: Asia/Shanghai is a feature of Kubernetes CronJob v1; ensure cluster supports this or document the version requirement clearly.

---

This PR is a straightforward release update and resource addition. Addressing the above points will improve robustness, maintainability, and operational safety.