Skip to content

fix(ci): repair broken test-e2e, cluster-init, and sdk pipelines - #418

Merged
anantadwi13 merged 7 commits into
mainfrom
fix-gh-workflows
Aug 19, 2026
Merged

fix(ci): repair broken test-e2e, cluster-init, and sdk pipelines#418
anantadwi13 merged 7 commits into
mainfrom
fix-gh-workflows

Conversation

@anantadwi13

@anantadwi13 anantadwi13 commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

CI across test-e2e, cluster-init, and sdk was broken by external
dependencies that changed out from under us (Bitnami Docker Hub tag
retention, k3d/k3s release assets, setuptools defaults). This chases
each failure down with a real repro and fixes them one at a time:

  • cluster-init image build: bitnami/kubectl:1.22.16 is gone from
    Docker Hub (Bitnami dropped legacy versioned tags) — fetch kubectl
    directly from the official Kubernetes release binaries instead.
  • sdk build: pandas' isolated sdist build was resolving an
    unconstrained setuptools>=80, which dropped pkg_resources and
    broke the legacy build (ModuleNotFoundError: pkg_resources) — pin
    setuptools<75, Cython<3, numpy<2 and build with
    --no-build-isolation so the outer pins are respected.
  • test-e2e cluster bootstrap (run-cluster-init action):
    • AbsaOSS/k3d-action@v2.3.0's default k3d (v5.4.1) is missing its
      checksums.txt release asset, so k3d's own install script 404s
      under set -e → pin k3d-version: v5.5.0.
    • That version's default k3s (v1.26.4) dropped the legacy
      --no-deploy flag → switched to --disable.
    • That same k3s version also dropped policy/v1beta1 and
      autoscaling/v2beta1, which the pinned Istio 1.12.5 install
      manifests require → pin the cluster's k3s image to
      v1.24.17-k3s1, keeping those APIs available.
  • test-e2e Postgres: bitnami/postgresql:12.13.0 is also gone from
    Docker Hub (only latest remains); the same tags are still published
    under bitnamilegacy/postgresql — repointed the e2e values there for
    turing/mlp/merlin's Postgres instances (all share one YAML anchor).

Test plan

  • make setup && make test passes locally for sdk on Python
    3.12.13 (matching the CI matrix) — 383 passed.
  • Reproduced and fixed the k3d checksum failure by running k3d's
    install.sh with TAG=v5.5.0 locally.
  • Reproduced and fixed the --no-deploy server crash by creating a
    local k3d cluster with the exact workflow args.
  • Confirmed policy/v1beta1/autoscaling/v2beta1 are served on
    k3s v1.24.17 but not v1.26.4, and ran the real Istio 1.12.5
    install against a k3s v1.24.17 cluster successfully.
  • Reproduced the Postgres ImagePullBackOff via docker pull,
    confirmed bitnamilegacy/postgresql:12.13.0 pulls, and verified
    via helm template that all three Postgres statefulsets resolve
    to the working image.
  • CI green on test-e2e (both matrix jobs), cluster-init, and
    sdk workflows for this PR.

🤖 Generated with Claude Code

anantadwi13 and others added 2 commits August 19, 2026 05:47
Trailing newline only, no content changes. Touches sdk/** and
infra/cluster-init/** so the PR exercises turing.yaml, sdk.yaml, and
cluster-init.yaml (gated by paths/paths-ignore filters) for a CI test.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- infra/cluster-init/Dockerfile: bitnami/kubectl:1.22.16 is no longer
  published on Docker Hub (Bitnami removed legacy versioned tags).
  Fetch the same kubectl version directly from the official Kubernetes
  release binaries instead of depending on a third-party image.

- sdk/Makefile: pip's isolated build environment (used to compile
  pandas from sdist, since no cp312 wheel exists for pandas<2) resolves
  setuptools per pandas' own unbounded pyproject.toml build
  requirement, ignoring whatever setuptools is pinned in the outer
  install. That fetched setuptools>=80, which dropped pkg_resources,
  breaking the legacy sdist build with ModuleNotFoundError:
  No module named 'pkg_resources'.

  Fix: pre-install setuptools<75 (still ships pkg_resources), Cython<3,
  and numpy<2 in the outer environment, then install requirements with
  --no-build-isolation so the sdist build reuses those instead of
  fetching its own unconstrained toolchain. pandas stays unpinned.

  Verified locally on Python 3.12.13 (matching the CI matrix): `make
  setup` completes without error and `make test` passes (383 passed).

Also drops the now-redundant no-op newline from the prior dummy commit
since these fixes already touch the required paths.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@codecov

codecov Bot commented Aug 18, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.38%. Comparing base (34c8f32) to head (6b520b2).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #418   +/-   ##
=======================================
  Coverage   96.38%   96.38%           
=======================================
  Files          26       26           
  Lines        2101     2101           
=======================================
  Hits         2025     2025           
  Misses         76       76           
Flag Coverage Δ
sdk-test-3.10 96.38% <ø> (ø)
sdk-test-3.11 96.38% <ø> (ø)
sdk-test-3.12 96.38% <ø> (ø)
sdk-test-3.9 96.38% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

test-e2e fails during "Setup local k8s cluster" with:
  curl: (22) The requested URL returned error: 404
  Failed to install k3d

Root cause: AbsaOSS/k3d-action@v2.3.0 defaults to k3d v5.4.1. That
release's k3d-linux-amd64 binary still exists on GitHub, but its
checksums.txt release asset does not (k3d only started publishing
checksums.txt from v5.5.0 onward). k3d's own install.sh unconditionally
fetches checksums.txt and verifies against it, so under `set -e` the
missing file aborts the install with curl exit code 22.

Fix: explicitly set k3d-version: v5.5.0 via the action's k3d-version
input, the earliest release with a complete asset set. Verified
locally by running k3d-io/k3d's install.sh with TAG=v5.5.0 - it
downloads, checksum-verifies, and installs cleanly (k3d v5.5.0,
default k3s v1.26.4-k3s1).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
test-e2e hung after the k3d-version pin (c0cbb84) because k3d v5.5.0's
default k3s (v1.26.4-k3s1) no longer accepts --no-deploy, causing the
server container to fatal on startup ("flag provided but not defined:
-no-deploy") and never report ready.

Verified locally: reproduced the hang with --k3s-arg "--no-deploy=...",
then confirmed cluster creation succeeds (all nodes Ready in ~20s)
using the exact workflow args with --disable=traefik,metrics-server
instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
test-e2e kept failing at the "Install Infrastructure" step (job/
turing-init-init timing out) even after the earlier k3d/k3s-arg fixes.
Root cause: k3d v5.5.0's default k3s (v1.26.4-k3s1, i.e. k8s 1.26) no
longer serves policy/v1beta1 (PodDisruptionBudget) or autoscaling/
v2beta1 (HorizontalPodAutoscaler) - both removed from k8s in 1.25 -
but Istio 1.12.5 (the version turing-init's chart installs by
default) hardcodes those APIs in its install manifests, so istioctl
install fails and the init job never completes.

Verified locally:
- Confirmed k3s v1.24.17-k3s1 still serves both policy/v1beta1 and
  autoscaling/v2beta1 (kubectl api-versions / raw API check).
- Ran the actual Istio 1.12.5 istioctl install (with the repo's
  IstioOperator config from infra/charts/turing-init/values.yaml)
  against a k3d cluster pinned to k3s v1.24.17-k3s1 - istiod installed
  successfully with no API errors.
- Re-created the cluster with the exact combined workflow args
  (1 server, 3 agents, port mapping, registry-create, --disable
  k3s-arg, and this --image pin) - all 4 nodes reach Ready on
  v1.24.17+k3s1 in under 20s.

Fix: add --image rancher/k3s:v1.24.17-k3s1 to the k3d-action args so
the cluster's Kubernetes version stays compatible with the pinned
Istio version, independent of whatever k3s version k3d itself
defaults to.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
test-e2e's turing-postgresql-0/-mlp-0/-merlin-0 pods were stuck in
ImagePullBackOff:
  Failed to pull image "docker.io/bitnami/postgresql:12.13.0": ...
  not found

Bitnami stopped retaining versioned tags on the free docker.io/bitnami/*
repos (only "latest" remains there now); historical tags were moved to
docker.io/bitnamilegacy/*. Since turing-postgresql/mlp/merlin all pin
image.tag: 12.13.0 (in infra/charts/turing/values.yaml and the vendored
mlp/merlin subchart defaults), every instance failed to pull.

infra/e2e/turing.values.yaml already centralizes postgresql config via
a shared YAML anchor reused by turing/mlp/merlin, so pointing the image
at bitnamilegacy there fixes all three in one place without touching
the vendored chart tarballs.

Verified locally:
- `docker pull docker.io/bitnami/postgresql:12.13.0` reproduces the
  exact "not found" error from the CI logs.
- `docker pull docker.io/bitnamilegacy/postgresql:12.13.0` succeeds.
- `helm template` with this change shows all three postgres
  statefulsets (turing, turing-mlp, turing-merlin) now resolving to
  docker.io/bitnamilegacy/postgresql:12.13.0.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@anantadwi13 anantadwi13 changed the title chore: dummy commit to trigger PR CI pipelines fix(ci): repair broken test-e2e, cluster-init, and sdk pipelines Aug 19, 2026
@anantadwi13 anantadwi13 self-assigned this Aug 19, 2026
@anantadwi13 anantadwi13 added the type: maintenance Chore changes label Aug 19, 2026
@anantadwi13
anantadwi13 requested a review from deryrahman August 19, 2026 03:14
…ro bug

sdk/publish (make build -> python setup.py sdist bdist_wheel) failed:
  TypeError: canonicalize_version() got an unexpected keyword argument
  'strip_trailing_zero'

setuptools 71.0.0 through at least 74.1.2 call
packaging.utils.canonicalize_version(..., strip_trailing_zero=...) from
_core_metadata.py during sdist/egg_info, but that kwarg only exists in
packaging>=22. requirements.txt pins mlflow>=1.26.1,<2.0.0, which
resolves to mlflow 1.30.1 and hard-requires packaging<22, so the two
constraints can't be satisfied together - whatever setuptools in that
range is installed, egg_info breaks.

setuptools 70.3.0 (last release below 71) doesn't have this call, so
capping below 71 avoids the conflict entirely while keeping
pkg_resources available (still only removed at 80, per the setuptools
cap fixed in e97dd1a).

Verified locally with the exact CI toolchain: pip install
"setuptools>=64,<71" ... then -r requirements.txt -r
requirements.dev.txt (resolves packaging==21.3, mlflow==1.30.1,
setuptools==70.3.0) - `make build` produces the sdist/wheel
successfully, and `make test` still passes (383 passed), matching the
result from the prior sdk fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

@deryrahman deryrahman left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@anantadwi13
anantadwi13 merged commit b8399c8 into main Aug 19, 2026
36 of 37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: maintenance Chore changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants