Started by GitHub push by ti-chi-bot[bot]Started by GitHub push by ti-chi-bot[bot]00253632536343925439251.009576957616285a6b44c85a4a37a83027975092ab283a389d6fe25a6b44c85a4a37a83027975092ab283a389d6fe2origin/main5a6b44c85a4a37a83027975092ab283a389d6fe25a6b44c85a4a37a83027975092ab283a389d6fe2origin/main5a6b44c85a4a37a83027975092ab283a389d6fe25a6b44c85a4a37a83027975092ab283a389d6fe2origin/mainhttps://github.com/PingCAP-QE/ci.gitfalse#16284392543022seed #16281628falsefalse16283669346SUCCESS1776312717379https://do.pingcap.net/jenkins/job/seed/1628/default-v5n4gprow-jobs/pingcap-qe/ci/presubmits.yaml.ci/verify-k8s-pod-yaml.shdocs/guides/CI.mdpipelines/ti-community-infra/test-prod/pod-prow_debug.yaml5a6b44c85a4a37a83027975092ab283a389d6fe21776312678000https://do.pingcap.net/jenkins/user/noreplynoreplynoreply@github.comci: verify pipeline pod YAML volumes blocks (#4526) ## Summary - keep the non-Python `sh + yq` structural validation for pipeline Pod YAML files - add supplemental `kubectl --dry-run=client` and `kubectl --dry-run=server` validation paths when the presubmit runs with in-cluster Kubernetes API access - inject a synthetic test `metadata.name` before calling `kubectl`, because Jenkins pod templates usually omit pod names - fix one real invalid Pod manifest already present on `main`: `pipelines/ti-community-infra/test-prod/pod-prow_debug.yaml` ## What is checked - YAML must parse successfully - `apiVersion` must be `v1` - `kind` must be `Pod` - `spec` must be a map - `spec.containers` must be a non-empty sequence - explicit null nodes are rejected anywhere in the Pod manifest - when in-cluster API access is available, `kubectl` also validates the rendered manifest after injecting a test pod name and namespace: - `kubectl apply --dry-run=client --validate=strict` - `kubectl apply --dry-run=server --validate=strict` ## Why this shape - plain schema validation alone is not enough for the repo-specific null-node cases we found - `kubectl` validation is useful as extra Kubernetes-side verification, but Jenkins pod templates need a synthetic test name before it can run cleanly - so the PR keeps the deterministic structural guardrail, and adds `kubectl` validation opportunistically when the presubmit environment supports it ## Findings from this follow-up - `pipelines/pingcap/tidb/latest/pod-ghpr_mysql_test.yaml` is already clean on current `main` - current `main` did still contain another real invalid case: `pipelines/ti-community-infra/test-prod/pod-prow_debug.yaml` with `spec.containers: null` - this PR fixes that file and adds a dedicated presubmit guardrail ## Validation - `sh .ci/verify-k8s-pod-yaml.sh` - stubbed `kubectl` validation locally to verify the script injects `metadata.name=ci-pod-yaml-validate`, injects the test namespace, and calls both client/server dry-run paths - `sh .ci/verify-k8s-pod-yaml.sh /tmp/invalid-null-volumes.yaml` -> fails as expected - `sh .ci/verify-k8s-pod-yaml.sh /tmp/invalid-null-containers.yaml` -> fails as expected - YAML parse for `prow-jobs/pingcap-qe/ci/presubmits.yaml` and `pipelines/ti-community-infra/test-prod/pod-prow_debug.yaml` -> `yaml-ok` - `.ci/update-prow-job-kustomization.sh` 2026-04-16 04:11:18 +00005a6b44c85a4a37a83027975092ab283a389d6fe2ci: verify pipeline pod YAML volumes blocks (#4526)add.ci/verify-k8s-pod-yaml.sheditprow-jobs/pingcap-qe/ci/presubmits.yamleditdocs/guides/CI.mdeditpipelines/ti-community-infra/test-prod/pod-prow_debug.yamlgithttps://do.pingcap.net/jenkins/user/noreplynoreply