refactor(pipelines/pingcap/tiflow): replace internal registry refs with public equivalents (PR1)

[wuhuizuo]

Summary

Replace all hub.pingcap.net and registry-mirror.pingcap.net image references in YAML files across 16 release branches under pipelines/pingcap/tiflow/.

Changes

• 96 YAML files modified, 155 replacements total
• hub.pingcap.net/jenkins/* → ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25
• hub.pingcap.net/jenkins/mysql:5.7 → docker.io/library/mysql:5.7
• hub.pingcap.net/wulifu/golang-tini:1.20.2 → ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25
• registry-mirror.pingcap.net/library/mysql:8.0.21 → docker.io/library/mysql:8.0.21

Branches affected

release-6.2, release-6.5, release-6.5-fips, release-7.1, release-7.1.0, release-7.2, release-7.3, release-7.4, release-7.5, release-7.6, release-8.0, release-8.1, release-8.2, release-8.3, release-8.4, release-8.5, release-9.0-beta

Testing

rg 'hub\.pingcap\.net|registry-mirror\.pingcap\.net' pipelines/pingcap/tiflow/ returns 0 matches after changes.

Risk

Low — configuration-only YAML changes replacing internal registry refs with public equivalents. Revert via single PR rollback.

Ref: FLA-233

[ti-chi-bot]

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

Summary

This pull request replaces internal image registry references (hub.pingcap.net and registry-mirror.pingcap.net) with public equivalents (ghcr.io and docker.io) across 96 YAML files in multiple release branches of the tiflow project. The changes are straightforward and primarily involve string replacements in configuration files. The overall quality of the PR is good, as it is configuration-only with low risk and clear testing verification. However, it lacks additional validation or documentation about potential impacts on external environments.

---

Critical Issues

None identified — the changes are straightforward YAML updates for image references.

---

Code Improvements

• Validation of Image Availability:

  • Issue: The PR assumes all replaced images are available and compatible with the configurations in the 96 YAML files. If any image is unavailable or incompatible, it could disrupt CI/CD workflows.

  • Solution: Add pre-merge validation steps to ensure all referenced images (ghcr.io/pingcap-qe/ci/jenkins and docker.io/library/mysql) exist and are accessible. Consider automating this check using a script to pull all images.

    # Example validation script
    images=(
      "ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25"
      "docker.io/library/mysql:5.7"
      "docker.io/library/mysql:8.0.21"
    )
    for image in "${images[@]}"; do
      docker pull "$image" || echo "Image $image is not accessible."
    done

---

Best Practices

• Testing Coverage:

  • Issue: The PR description mentions running rg command to confirm no internal registry references remain, but it does not specify whether functional tests were conducted to ensure CI/CD pipelines are unaffected by the image changes.
  • Solution: Include a note in the PR description confirming that CI/CD workflows were tested successfully after the image changes. If possible, execute a test run of the pipelines from one or more branches to validate functionality.

• Documentation:

  • Issue: The PR does not include documentation on why specific public images were chosen or any potential differences between the internal and public images (e.g., tags, configurations).

  • Solution: Add a README or inline comments explaining the rationale for image replacements, particularly for ghcr.io/pingcap-qe/ci/jenkins and the specific version tag v2026.4.12-10-gc29110c-go1.25. This will help future developers understand the context of the changes.

    # Example comment in YAML
    containers:
      - name: golang
        # Public registry image replacing hub.pingcap.net/jenkins/centos7_golang-1.19
        image: "ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25"

• Consistency in Image Tags:

  • Issue: While most public images use specific tags (e.g., v2026.4.12-10-gc29110c-go1.25), some internal registry images used generic tags like latest. There is no explanation for this change in the image tagging strategy.
  • Solution: Ensure consistency in the use of specific vs generic tags. If latest tags were previously used intentionally (e.g., for flexibility), document why fixed tags are now preferred.

---

Summary of Suggested Actions

1. Validate the availability of replaced images across public registries.
2. Test CI/CD pipelines on at least one branch to confirm functionality post-change.
3. Add documentation explaining the image selection and differences between internal and public registries.
4. Ensure consistent use of specific image tags, documenting any changes in strategy.

[ti-chi-bot]

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

Summary

This pull request replaces internal registry references (hub.pingcap.net and registry-mirror.pingcap.net) in 96 YAML files across multiple release branches with public equivalents (docker.io and ghcr.io). The changes ensure all container images are sourced from publicly accessible registries, improving transparency and accessibility. The approach is straightforward, involving direct string replacements in configuration files. The PR is low risk as it involves non-functional configuration changes, and the testing methodology (regex verification) is sufficient for its scope. Overall, the changes are well-executed.

---

Critical Issues

None identified.

---

Code Improvements

• File: Multiple YAML files
  • Issue: The new image references (docker.io/library/mysql:5.7 and ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25) are hardcoded, which could lead to maintenance challenges if these image versions are updated in the future.
  • Suggestion: Use variables or centralized configuration (e.g., environment files or Helm chart values) to manage image references for easier updates and consistency across branches. Example:

    containers:
      - name: mysql1
        image: "${MYSQL_IMAGE}" # Reference variable for image

    Update the deployment pipeline to inject these variables during runtime.

---

Best Practices

1. Testing Coverage

   • Issue: While regex-based validation ensures that the replacements are complete, it does not verify the functionality of the new images in the deployment process.
   • Suggestion: Perform end-to-end integration tests on a subset of branches to ensure the new image references function as expected. This is especially critical for images that were previously sourced from private registries.

2. Documentation

   • Issue: The PR does not include notes on how external registries were chosen or why specific versions of images were selected.
   • Suggestion: Include brief documentation or comments in the YAML files or the PR description detailing the rationale for the specific public image versions. This can help future maintainers understand the context of these choices.

3. Consistency

   • File: Various YAML files
   • Issue: The imagePullPolicy is inconsistent across files (e.g., Always in some, missing in others). This could lead to unpredictable behavior in deployment environments.
   • Suggestion: Standardize imagePullPolicy across all configurations, preferably setting it explicitly (e.g., Always or IfNotPresent) based on the desired behavior:

     containers:
       - name: mysql1
         image: docker.io/library/mysql:5.7
         imagePullPolicy: Always

---

Conclusion

This PR generally achieves its goal effectively, with low risk and minimal implementation complexity. Addressing the suggestions above would enhance maintainability, testing robustness, and documentation clarity.

[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 YAML configuration files to replace internal container registry references with public equivalents, ensuring broader accessibility and eliminating dependency on internal infrastructure. The changes span multiple branches and affect 96 files, with 155 replacements. The approach is straightforward, involving direct substitution of image tags. Overall, the changes are well-documented and low-risk, though some minor issues could be addressed to improve maintainability and consistency.

---

Critical Issues

None identified. The changes are configuration-only and low-risk, with no functional or security concerns apparent.

---

Code Improvements

• File: .github/workflows/release-ci-runtime-images.yaml
  Line: 59-60
  Issue: The addition of multiple go-profile versions introduces inconsistency with the naming convention used in the skaffold.yaml file, where profiles are defined with specific version numbers (e.g., go-1.19). This inconsistency might cause confusion or management overhead in the future.
  Suggested Solution: Ensure consistent naming conventions across configuration files. For example:

  strategy:
    matrix:
      module: [ci]
      go-profile: [go-1.19, go-1.20, go-1.25]

• File: dockerfiles/ci/skaffold.yaml
  Lines: 26-46
  Issue: Multiple new profiles for Go versions (go-1.19, go-1.20, etc.) introduce redundancy. Consider programmatically generating these profiles to reduce duplication and maintenance overhead.
  Suggested Solution: Use YAML anchors or scripting to define reusable templates for similar profiles. Example:

  profiles:
    - name: go-version
      patches:
        - op: replace
          path: /build/tagPolicy/customTemplate/template
          value: "{{ .GIT }}-go{{ .VERSION }}"
        - op: add
          path: /build/artifacts/0/docker/buildArgs
          value:
            GOLANG_VERSION: "{{ .VERSION }}"

---

Best Practices

• Documentation:
  Files: All YAML files
  Issue: The PR description is detailed, but in-file comments explaining why specific public images are chosen would improve maintainability. For example, why ghcr.io/pingcap-qe/ci/jenkins is preferred over alternatives.
  Suggested Solution: Add comments in YAML files for clarity:

  image: "ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25" # Public registry for Jenkins images; maintained by PingCAP QE team

• Testing Coverage:
  Issue: While the rg command confirms replacement accuracy, no integration or smoke tests are mentioned to verify functionality with the updated images.
  Suggested Solution: Run integration tests across all affected branches to ensure compatibility and document the results in the PR.

• Version Tagging:
  Files: All YAML files containing image references
  Issue: Specific docker image tags (e.g., ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25) are used, which is good for reproducibility but could lead to outdated dependencies.
  Suggested Solution: Implement an automated process to periodically update and validate image tags with the latest versions.

---

Additional Notes

• Consider consolidating repetitive YAML files across branches into reusable templates to reduce duplication. Tools like Helm or Kustomize could be helpful for managing Kubernetes configurations consistently across multiple branches.
• The PR rollback strategy is mentioned as "low-risk," but a detailed rollback plan (e.g., script or process) would further mitigate risks during large-scale changes like 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 updates image references in 96 YAML files across multiple branches to replace internal registry URLs (hub.pingcap.net and registry-mirror.pingcap.net) with public equivalents (docker.io and ghcr.io). The changes are strictly configuration-based, aiming to enhance accessibility and remove dependency on internal registries. The approach is straightforward, involving direct replacements of image strings. Overall, the changes appear low-risk with minimal impact on functionality, but testing and validation of the new image sources are essential.

---

Critical Issues

No critical issues identified.

---

Code Improvements

1. Validation of Image Availability:
   • File(s): All modified YAML files.
   • Issue: The new images (e.g., docker.io/library/mysql:5.7 and ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25) must be verified to exist and be accessible in the target registries to prevent runtime errors in pipelines.
   • Suggested Solution: Add a verification step in CI/CD pipelines to pull these images and confirm availability before merging this PR.

---

Best Practices

1. Testing Coverage:

   • File(s): All modified YAML files.
   • Issue: While the PR description indicates that rg finds no remaining internal registry references, functional testing of affected pipelines is needed to ensure compatibility with public images.
   • Suggested Solution: Run affected pipelines across all branches to validate the behavior with the updated images.

2. Documentation:

   • File(s): PR description or related documentation.
   • Issue: The PR description lacks a link to image source repositories or tags, which would be useful for tracking updates or troubleshooting.
   • Suggested Solution: Include links to the repositories (e.g., https://github.com/org/repo) or references to internal documentation explaining the change.

3. Versioning Consistency:

   • File(s): pipelines/pingcap/tiflow/release-8.5/pod-merged_unit_test.yaml and similar files.
   • Issue: The new image version (ghcr.io/pingcap-qe/ci/jenkins:v2026.4.12-10-gc29110c-go1.25) should be checked for backward compatibility across branches. Older branches might have dependencies incompatible with the newer image version.
   • Suggested Solution: Confirm compatibility of the image version with all branches or consider version-specific images for older branches.

4. Consistency in Quotation Marks:

   • File(s): Multiple YAML files (e.g., release-6.5-fips/pod-pull_dm_compatibility_test.yaml).
   • Issue: Mixed usage of single (') and double (") quotes for image strings affects readability and consistency.
   • Suggested Solution: Standardize the usage of either single or double quotes across all YAML files to align with the project's preferred style.

---

Conclusion

The PR effectively updates image references but requires validation of the new image sources, compatibility testing across branches, and minor improvements to documentation and style consistency. Addressing these points will ensure a smooth transition and mitigate potential runtime issues.

[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 replaces internal container image references (hub.pingcap.net and registry-mirror.pingcap.net) with public equivalents (ghcr.io and docker.io) across 96 YAML files spanning multiple release branches. The changes are straightforward, involving string replacements in configuration files. The overall implementation appears correct, and the risk is low given the non-executable nature of the changes. However, there are minor areas for refinement to ensure consistency and future maintainability.

---

Critical Issues

No critical issues identified.

---

Code Improvements

• Version consistency:

  • Ensure the versions of the ghcr.io/pingcap-qe/ci/jenkins images match the intended functionality across all YAML files. For example, the transition from centos7_golang-1.23:latest to v2025.12.7-3-g1c0b8cf-go1.23 (or similar) should be verified for correctness.
  • Suggested action: Confirm that the specific versions mapped to these new public images are functionally equivalent to the internal ones they replace. If any version mismatches exist, update accordingly.

• Future-proofing image references:

  • In some files, the new image tags (e.g., v2024.10.8-119-g4e56df7-go1.21) are highly specific. While this ensures precision, it might hinder maintainability if the versions need frequent updates.
  • Suggested action: Consider using a less specific tag (e.g., latest or a major version like go1.21) unless the exact version is critical for compatibility.

---

Best Practices

• Testing adequacy:

  • While the PR description mentions testing the changes using rg to ensure no internal references remain, it is unclear if the new public images have been validated in a staging environment.
  • Suggested action: Run integration tests for each affected pipeline to confirm the new images behave as expected.

• Documentation update:

  • The PR introduces public image URLs but does not update documentation or notes within the YAML files to explain the change. This context may be important for future maintainers.
  • Suggested action: Add comments in the YAML files or update related documentation to explain why public images were introduced, noting any implications (e.g., external dependencies).

---

Additional Notes

• The PR touches configuration files across numerous branches. Ensure alignment with any branch-specific requirements if configuration differs across versions.
• If these changes are part of a broader effort to deprecate internal registries, consider documenting the transition plan for maintainers and contributors.

[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:

• pipelines/OWNERS [wuhuizuo]

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