Add MariaDB Operator compatibility scraper

[goodguypeci-design]

I added MariaDB Operator to the compatibility catalog.

The scraper reads the first-party Helm index and only uses entries.mariadb-operator; the cluster and CRD companion charts are intentionally left out of the app table. For each chart entry it records the chart version, app version, rendered image list, and the Kubernetes range from Helm's kubeVersion constraint. That Kubernetes list is the chart install constraint, not a separate runtime test matrix.

I also added pruning for stale representative rows, so a newer patch such as 25.10.4 does not get hidden by an older 25.10.x row with the same Kubernetes range. After Greptile flagged a future strict-bound edge case, I tightened the constraint parser and added coverage for patch-overlap ranges such as <1.29.1.

Sources:

• https://mariadb-operator.github.io/mariadb-operator/index.yaml
• https://github.com/mariadb-operator/mariadb-operator/blob/main/deploy/charts/mariadb-operator/Chart.yaml
• https://github.com/mariadb-operator/mariadb-operator/releases
• https://github.com/mariadb-operator/mariadb-operator#kubernetes-compatibility

I checked this with py_compile, the MariaDB scraper tests, a direct live scraper run through Helm, a generated YAML sanity check for representative versions/chart versions/images, and git diff --check.

Related to #4165.

[soffi-ai]

Soffi AI Summary

Adds MariaDB Operator to the platform's compatibility catalog so users can see which Kubernetes versions are supported by each MariaDB Operator release.

The implementation introduces a new Python scraper (utils/compatibility/scrapers/mariadb-operator.py) that fetches the official Helm index, extracts chart/app versions and Kubernetes version constraints, and writes the results to static/compatibilities/mariadb-operator.yaml. Key design decisions:

• Only the mariadb-operator chart is indexed; the companion cluster and CRD charts are intentionally excluded.
• Kubernetes version ranges are derived from the Helm chart's kubeVersion constraint, not a separate runtime test matrix.
• A "representative rows" deduplication pass ensures only meaningful per-minor-version entries are kept, and a pruning step removes stale rows when a newer patch supersedes an older one with the same Kubernetes range.
• The constraint parser was hardened to correctly handle patch-overlap ranges (e.g., <1.29.1) after an edge-case was identified, ensuring minor versions are correctly included or excluded.

A comprehensive unit test suite (utils/compatibility/tests/test_mariadb_operator.py) covers constraint parsing, representative-row selection, stale-row pruning, and the full scrape pipeline. The test module uses importlib to load both the local utils.py helpers and the scraper directly from disk, avoiding import-path issues. The generated YAML and manifest entry are also committed.

Changes

MariaDB Operator compatibility scraper

• Introduces the MariaDB Operator scraper that reads the first-party Helm index, parses kubeVersion constraints into expanded Kubernetes minor-version lists, deduplicates by representative rows, prunes stale entries, and writes results to static/compatibilities/mariadb-operator.yaml. Also adds the generated YAML output and the manifest entry. (ca6737a)
• Tightens the Kubernetes constraint parser to correctly handle patch-overlap upper bounds (e.g., <1.29.1), ensuring minor versions that partially overlap such a bound are still included in the compatibility list rather than incorrectly dropped. (b1794c0)
• Fixes test module loading so the test file uses importlib to load the local utils.py helpers before importing the scraper, eliminating import failures when tests are run outside the scraper directory. (e587988)

---

Updated: 2026-09-08 13:59 UTC

Deploy in Soffi

[greptile-apps]

Greptile Summary

Adds MariaDB Operator to the compatibility catalog.

• Registers the new catalog in the compatibility manifest.
• Scrapes stable operator-chart releases from the first-party Helm index.
• Converts Helm Kubernetes constraints into catalog minor-version lists and prunes superseded patch representatives.
• Adds generated compatibility metadata and focused parser, filtering, and pruning tests.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking constraint-parser edge case that should be hardened for future strict Helm bounds.

Current generated data uses supported non-strict bounds, while the only accepted concern affects future strict constraints by projecting them incorrectly to Kubernetes minors.

Files Needing Attention: utils/compatibility/scrapers/mariadb-operator.py, utils/compatibility/tests/test_mariadb_operator.py

Important Files Changed

Filename	Overview
utils/compatibility/scrapers/mariadb-operator.py	Implements Helm-index extraction, Kubernetes constraint parsing, representative-row selection, and stale-row pruning; strict-bound parsing can omit valid Kubernetes minors.
utils/compatibility/tests/test_mariadb_operator.py	Covers minimum and upper constraints, chart filtering, stable-version selection, and stale-row pruning, but omits strict-bound edge cases.
static/compatibilities/mariadb-operator.yaml	Adds generated MariaDB Operator release, chart, image, and Kubernetes compatibility metadata.
static/compatibilities/manifest.yaml	Registers the MariaDB Operator compatibility catalog.

_{Reviews (1): Last reviewed commit: "Add MariaDB Operator compatibility scrap..." | Re-trigger Greptile}

[greptile-apps]

Strict Bounds Drop Valid Minors

If a chart publishes a strict Kubernetes bound, this parser can omit a valid minor version. It discards the patch component and shifts the whole minor, so >1.26.0 excludes Kubernetes 1.26 even though 1.26.1 satisfies the constraint, while <1.29.1 excludes 1.29 even though 1.29.0 satisfies it. Preserving patch semantics before converting the range to minor-level entries would prevent the catalog from reporting an unnecessarily narrow install range; tests should also cover these strict-bound cases.

[goodguypeci-design]

Rebased this on the current master and re-ran the focused compatibility checks locally.

The required-label check is failing because the PR has no label, but GitHub will not let me add the enhancement label from my fork account. Could you add the label when you get a chance?

[goodguypeci-design]

I checked the failing CI logs as well. The compatibility checks themselves are still green; the red Test job stops during docker/login-action with Password required, then the Slack notification step fails because SLACK_WEBHOOK_URL is empty.

So this looks like the usual missing repo secrets on a forked PR, plus the label check I mentioned above, rather than a scraper/test failure from this patch.

[goodguypeci-design]

Pushed e587988 for the strict patch-bound case. The parser now keeps the boundary minor when valid patch versions still exist, and the regression covers those > / < patch overlaps. python -m unittest tests.test_mariadb_operator -v passes locally (5 tests).