Add Tyk Operator compatibility scraper

[KUANPEIEN]

Summary

• add Tyk Operator compatibility metadata
• add a scraper for the Tyk Operator documentation and release notes
• register Tyk Operator in the compatibility manifest

Sources

• Tyk Operator compatibility matrix: https://tyk.io/docs/api-management/automations/operator
• Tyk Operator release notes dependency tables: https://tyk.io/docs/developer-support/release-notes/operator
• Tyk public Helm chart index: https://helm.tyk.io/public/helm/charts/index.yaml

Validation

• python -c "import importlib; importlib.import_module('scrapers.tyk-operator').scrape()"
• python -m py_compile utils/compatibility/scrapers/tyk-operator.py
• python -c "import yaml; yaml.safe_load(open('static/compatibilities/tyk-operator.yaml')); yaml.safe_load(open('static/compatibilities/manifest.yaml')); print('yaml ok')"
• git diff --check

[soffi-ai]

Soffi AI Summary

This PR adds Tyk Operator to the Plural Console's compatibility tracking system, enabling users to see which Kubernetes versions and Tyk Gateway versions are compatible with each Tyk Operator release.

The work involves three components:

1. A new Python scraper (utils/compatibility/scrapers/tyk-operator.py) that fetches compatibility data from two Tyk documentation sources — the operator compatibility matrix page and the release notes page. It parses both HTML tables and release note sections to extract Kubernetes version ranges and Tyk Gateway version requirements per operator version, with the release notes source taking priority when both sources cover the same operator version (as it provides a broader tested range).
2. A generated compatibility YAML file (static/compatibilities/tyk-operator.yaml) containing the scraped compatibility matrix for operator versions from 0.x through 1.4.2, including supported Kubernetes versions and Tyk Gateway requirements for each release.
3. A manifest registration (static/compatibilities/manifest.yaml) adding a single entry to register Tyk Operator alongside the other tracked add-ons.

Follow-up commits refined the scraper's source priority logic (release notes over compatibility matrix when versions overlap) and fixed the requirements schema structure to correctly represent Tyk Gateway version constraints as structured objects rather than plain strings.

Commits

Commit	Summary
85a650a	Introduces the Tyk Operator compatibility scraper, the initial static compatibility YAML, and registers Tyk Operator in the manifest. The scraper fetches Kubernetes version ranges and Tyk Gateway requirements from Tyk's documentation and release notes pages.
2fad841	Clarifies source priority in the scraper: when both the compatibility matrix page and the release notes page cover the same operator version, the release notes range is kept because it reflects a broader set of tested Kubernetes versions.
0e6c06c	Fixes the requirements schema so Tyk Gateway version constraints are emitted as structured OrderedDict objects (with 'name' and 'version' keys) rather than bare strings, matching the format expected by the compatibility framework.

---

Updated: 2026-08-17 14:10 UTC

Deploy in Soffi

[greptile-apps]

Greptile Summary

This PR adds Tyk Operator to the compatibility tracking system, introducing a new YAML data file, registering the operator in the manifest, and providing a Python scraper that merges data from two Tyk documentation sources (the compatibility matrix page and the per-release release notes).

• tyk-operator.yaml: 13 version entries (v0.13.0–v1.4.2) with Kubernetes version lists and Tyk Gateway requirements; versions 1.2.0–1.4.x have empty requirements, consistent with what the compat matrix currently covers; chart_version fields will be populated on the next full scraper run.
• tyk-operator.py: The scraper uses release-notes kube ranges as the primary source and the compat table as a fallback for unlisted versions; when a version appears in both, the requirements update in the merge branch is a no-op (both paths draw from the same gateway_requirements dict), and the compat table's explicit per-version Y/N data is silently discarded in favor of the broader range — this design choice is not documented and could surprise future maintainers.
• manifest.yaml: tyk-operator is prepended as the first entry.

Confidence Score: 4/5

Safe to merge; all changes are additive and isolated to the new Tyk Operator entry

The scraper's merge loop has one dead code line (redundant requirements reassignment) and silently prefers release-notes kube ranges over the compat table's per-version marks for overlapping versions — neither causes incorrect data today but could confuse future maintenance. Everything else follows the patterns established by other scrapers in the repo.

The merge logic in utils/compatibility/scrapers/tyk-operator.py (lines 166–171) would benefit from a short comment explaining source priority

Important Files Changed

Filename	Overview
utils/compatibility/scrapers/tyk-operator.py	New scraper using two data sources (release notes ranges + kube compat table); merge logic silently discards the compat table's per-version Y/N data when a version already exists from release notes, and the requirements update in that same branch is a no-op
static/compatibilities/tyk-operator.yaml	New compatibility file with 13 version entries; versions 1.2.0–1.4.x have empty requirements (consistent with available Tyk Gateway compatibility data); no chart_version fields yet (expected to be populated when the scraper runs in full)
static/compatibilities/manifest.yaml	Adds tyk-operator as the first entry in the manifest names list

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

[greptile-apps]

Redundant requirements update in merge branch

For versions that appear in both the release notes and the kube compatibility table, version_info["requirements"] is always gateway_requirements.get(version, []) — the same value already stored when the entry was created from the release notes (line 161). The update on line 169 is therefore always a no-op, which may mask the fact that the kube version list from the compatibility table is silently discarded for these versions. A comment explaining that release-notes kube ranges take precedence over the compat table's per-version Y/N marks would help future maintainers understand this intentional priority, especially since the release-notes ranges can be broader (e.g., v1.4.2 lists kube 1.35 from a range while the table may show fewer confirmed versions).

[KUANPEIEN]

Hi, this should be ready for review. I addressed the bot feedback by documenting the source-priority behavior in the scraper. Happy to adjust if Tyk Operator is not a good fit for the common compatibility set.