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 integrates Tyk Operator into the Plural Console's add-on compatibility tracking system. The motivation is to give Console users visibility into which versions of the Tyk Operator (a Kubernetes-native API management operator) are compatible with which Kubernetes versions and Tyk Gateway versions — the same information surfaced for other managed add-ons in the platform.

Three coordinated changes accomplish this:

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 merges both sources intelligently, preferring the broader Kubernetes range reported in the release notes when both cover the same operator version. It also captures Tyk Gateway version requirements per operator release.
2. A pre-seeded compatibility YAML (static/compatibilities/tyk-operator.yaml) with metadata (icon, Git URL, Helm repo, chart name) and version entries spanning operator releases from 0.17.0 through 1.4.2, each annotated with supported Kubernetes versions and any Tyk Gateway requirements.
3. A manifest registration (static/compatibilities/manifest.yaml) that adds tyk-operator to the catalog of tracked add-ons recognized by the Console.

Commits

Commit	Summary
ce4ec60	Introduces the initial Tyk Operator compatibility scraper, the pre-populated compatibility YAML (versions 0.17.0–1.4.2 with Kubernetes and Tyk Gateway requirements), and registers the add-on in the compatibility manifest.
bc21405	Adds inline documentation to the scraper clarifying source priority: when both the release notes page and the compatibility matrix page cover the same operator version, the release notes range (broader tested Kubernetes versions) takes precedence.

Deploy in Soffi

---

Updated: 2026-07-13 17:10 UTC

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