refactor(apps/prod,apps/prod2): move tibuild to prod2 env

[wuhuizuo]

No description provided.

[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 refactors the deployment of the tibuild service by moving it from the prod environment to the prod2 environment. The approach involves removing tibuild from apps/prod/kustomization.yaml and adding it under apps/prod2/tibuild with a versioned directory structure (v1 and v2). The deployment, service, ingress, and configuration files are relocated and slightly updated to reflect the new environment and secret setup. Overall, the changes are organized and mostly consistent, but there are some points to address to improve maintainability and clarity.

---

Critical Issues

• Potential Secret Name Mismatch (apps/prod2/tibuild/v1/deployment.yaml, lines ~41-50)
  • The volume references a secret named v1-config which is created by external-secret-config.yaml. While this matches, verify that the secret data (e.g., config.yaml) matches what the application expects. Secret key names and formats should be consistent with the original tibuild-configs secret to avoid runtime failures.
  • Suggestion: Confirm the secret contents and update either the secret or the deployment accordingly.

---

Code Improvements

• Consistency in Volume and VolumeMount Naming

  • In deployment.yaml the volume and volumeMount are renamed from configs to config. This breaks consistency with the original name and might cause confusion or errors if other parts expect the older name.
  • Suggestion: Maintain the original naming (configs) unless there is a specific reason to change it. If changed, update all relevant references and document the reason.

  volumeMounts:
    - name: configs     # instead of config
      mountPath: "/app/configs"
      readOnly: true
  volumes:
    - name: configs
      secret:
        secretName: v1-config

• Versioned Directory Structure Clarity

  • The introduction of v1 and v2 directories under prod2/tibuild is good for versioning but the apps/prod2/tibuild/kustomization.yaml replaces references to v2/external-secret-config.yaml and v2/release.yaml with just v1 and v2 directories, which is ambiguous.
  • Suggestion: Explicitly list resources in the kustomization.yaml files or ensure the directory structure is clear and documented to avoid confusion.

• Image Tag Update Justification

  • The image tag was updated from v2025.11.16-1-g616fce1 to v2025.12.14-1-g9dbf1e7. This is presumably intentional, but there is no PR description or comment explaining the reason.
  • Suggestion: Add a comment or PR description explaining the image update to help reviewers understand the change context.

---

Best Practices

• Missing PR Description and Context

  • The PR description is empty, which makes it hard to understand the motivation or the scope fully.
  • Suggestion: Add a clear description explaining why tibuild is moved from prod to prod2, what impact this has, and any required follow-up actions.

• Documentation for New Environment

  • Consider adding or updating README or deployment documentation to reflect the addition of prod2 and the new versioned tibuild configuration.

• Testing Coverage

  • There is no indication of tests or validation steps for this migration.
  • Suggestion: Add or update integration tests or deployment validation steps to ensure tibuild works correctly in prod2.

• Naming Conventions

  • The secret name v1-config is generic; consider a more descriptive name like tibuild-v1-config to avoid collisions and improve clarity.

---

Overall, this PR moves the tibuild component cleanly but would benefit from improved documentation, consistency checks, and verification of secret configurations to ensure a smooth transition.

[gemini-code-assist]

Summary of Changes

Hello @wuhuizuo, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request undertakes a significant refactoring of the tibuild application's deployment strategy. It migrates the application's Kubernetes configurations from the prod environment to a newly established, versioned structure within the prod2 environment. This change aims to consolidate tibuild deployments under prod2 and provides a robust framework for managing distinct application versions, beginning with an updated v1 and setting the stage for v2.

Highlights

• Application Relocation: The tibuild application's Kubernetes configurations have been moved from the apps/prod environment to apps/prod2.
• Versioned Deployment Structure: A new versioned directory structure (v1, v2) has been introduced within apps/prod2/tibuild to manage different versions of the application, enhancing organization and future scalability.
• Updated tibuild v1 Configuration: The v1 deployment for tibuild in prod2 includes an updated Docker image and refactored secret management, now utilizing ExternalSecret with a new v1-config naming convention.
• Preparation for tibuild v2: A kustomization.yaml file has been added for tibuild/v2, laying the groundwork for future v2 deployments within the prod2 environment.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the tibuild application by moving it from the prod to the prod2 environment and splitting it into v1 and v2 configurations. The overall file structure changes are logical. However, I've found a critical issue in the Kustomize configuration for the v1 application that will prevent it from deploying correctly. The v1 configuration specifies an incorrect namespace and contains a YAML syntax error. My review comment provides details on how to resolve this.

[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 refactors the deployment of the tibuild app by moving it from the prod environment to the prod2 environment. It achieves this by removing tibuild from the apps/prod/kustomization.yaml and reorganizing all related tibuild manifests under apps/prod2/tibuild/ with versioned subdirectories (v1, v2). The PR also updates image versions and secret references accordingly. Overall, the changes are well-structured and mostly consistent, improving environment separation and maintainability.

---

Critical Issues

• Secret name inconsistency
  • File: apps/prod2/tibuild/v1/deployment.yaml (lines ~40-50)
  • Issue: The volume references secret v1-config, which must exactly match the secret created by external-secret-config.yaml. This looks consistent, but confirm that the secret name v1-config is properly provisioned in the cluster. Any mismatch will cause pod startup failures.
  • Suggestion: Double-check that the secret name in external-secret-config.yaml (v1-config) matches the secretName in the deployment. Consider adding a comment to clarify this linkage.

---

Code Improvements

• Namespace specification consistency

  • File: apps/prod2/tibuild/v1/kustomization.yaml (line 2)
  • Issue: The namespace field is removed compared to the previous apps/prod/tibuild/kustomization.yaml (which had namespace: apps). However, the deployment specifies namespace: tibuild at a higher level in apps/prod2/tibuild/kustomization.yaml. This might cause confusion or deployment issues if the namespaces are not consistent across all resources.
  • Suggestion: Explicitly add or document namespace settings in each kustomization or ensure the base apps/prod2/tibuild/kustomization.yaml sets it correctly. Prefer explicitly specifying the namespace in each kustomization for clarity.

• Kustomization resource lists formatting

  • Files: apps/prod/tibuild/kustomization.yaml → apps/prod2/tibuild/v1/kustomization.yaml
  • Issue: The original used a dash list with indentation for resources, the new version uses inline dash-prefixed resources. Both work, but it is best to be consistent with formatting for readability.
  • Suggestion: Align style with the rest of the repo’s kustomization files (typically one item per line with consistent indent).

• Versioning folder structure clarity

  • Files: apps/prod2/tibuild/v1/, apps/prod2/tibuild/v2/
  • Issue: The use of both v1 and v2 directories for tibuild versions is good for version segregation. However, the root apps/prod2/tibuild/kustomization.yaml now references both by - v1 and - v2, but the v2 folder contents are minimal (only external-secret-config.yaml and release.yaml) and not shown fully.
  • Suggestion: Ensure that the v2 folder contains all necessary resources (deployment, service, ingress) or document why it differs. Consider adding a README in prod2/tibuild explaining the versioning strategy.

---

Best Practices

• PR description improvement

  • Issue: The PR description is empty, which misses the opportunity to explain the motivation, testing done, and usage notes.
  • Suggestion: Add a brief description to the PR explaining why tibuild is moved to prod2, any impact on users, and any required post-merge actions.

• Testing coverage and validation

  • Issue: No mention or evidence of testing (e.g., CI pipeline runs, deployment validation, smoke tests).
  • Suggestion: Ensure this environment move is covered by integration tests or manual deployment validation. Add notes or tests if possible.

• Comments and documentation

  • Files: All moved files (deployment.yaml, kustomization.yaml, external-secret-config.yaml)
  • Issue: No comments explaining purpose of resources or differences between v1 and v2.
  • Suggestion: Add comments or README clarifying the intent of each version directory and key configuration differences.

---

Overall, this PR achieves a clean environment migration for tibuild with proper resource relocation and versioning. Addressing namespace clarity, documentation, and testing coverage will improve maintainability and reduce risk during deployment.

[wuhuizuo]

Fixed the review issues:

1. Removed namespace: apps line from apps/prod2/tibuild/v1/kustomization.yaml to prevent namespace conflict with the parent tibuild namespace
2. Corrected the indentation for the resources list in apps/prod2/tibuild/v1/kustomization.yaml

Changes are committed and pushed to resolve the kustomization configuration problems mentioned in the review.

[wuhuizuo]

The critical kustomization issues have been resolved:\n\n✅ Removed from to prevent namespace conflict\n✅ Fixed YAML indentation in the resources list\n\nThe changes are committed and pushed. This resolves the critical deployment issues mentioned in the review.

[wuhuizuo]

/approve

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wuhuizuo

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• apps/prod/OWNERS [wuhuizuo]
• apps/prod2/OWNERS [wuhuizuo]

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

[wuhuizuo]

/hold

[wuhuizuo]

/unhold