fix(orchestration): derive the plugin docs link from the catalog

[vfanucci]

/orchestration/<slug> guessed the plugin docs link as /plugins/plugin-<4th class segment>, which gives /plugins/plugin-jdbc for io.kestra.plugin.jdbc.duckdb.Query and /plugins/plugin-microsoft for the Fabric class. Neither is a page: both 301 to the /plugins index (5 links in the 16 Sept crawl: duckdb, postgres, snowflake, sql-server, microsoft-fabric).

The link is now derived from the catalog through buildTaskUrls (group segment of the element's canonical URL), with the previous guess kept as fallback when the class is unknown.

[github-actions]

☁️ Cloudflare Worker Preview Deployed!

🔗 https://ks-fix-301-orchestration-plugin-l-docs.kestra-io.workers.dev
🔗 https://91c282d8-docs.kestra-io.workers.dev

🔦 Lighthouse Benchmark

Tested on 2026-09-21 08:14 UTC  ·  links point to https://ks-fix-301-orchestration-plugin-l-docs.kestra-io.workers.dev
Compared against main baseline from 2026-09-21
Runner CPU index per shard: 2494, 2320, 2332, 2498 (baseline: 2761, deltas hidden on 14 page(s))

Scores (0–100, higher is better)

Page	Performance	Accessibility	Best Practices	SEO
Home	89	84	77	92
Get Started	85	83	77	100
Pricing	98	92	77	100
Enterprise	94	83	77	100
Cloud	92	81	77	100
About Us	98	91	77	100
Docs Landing	90	88	77	92
Contribute to Kestra (simple docs)	90	88	77	92
Flow (full featured docs)	91	90	77	92
Blog Index	84	91	77	100
Blog Post (sample)	88	88	77	100
VS Page (sample)	97	88	77	100
Plugins Landing	96	81	77	92
Plugin Page (sample)	98	88	77	100
Plugin Debug Page (sample)	86	88	77	100
Plugin Debug Return Page (sample)	84	88	77	100
Blueprints Landing	82	91	77	100
Blueprint Audit Logs CSV Export	82	92	77	100

Core Web Vitals (lower is better)

Page	LCP	FCP	TBT	CLS	Speed Index
Home	1.37 s	0.65 s	163 ms	0.000	1.75 s
Get Started	1.58 s	0.70 s	231 ms	0.000	1.20 s
Pricing	1.04 s	0.68 s	60 ms	0.000	1.06 s
Enterprise	1.55 s	0.54 s	68 ms	0.000 🟢	1.23 s
Cloud	1.65 s	0.67 s	102 ms	0.049	1.06 s
About Us	1.00 s	0.59 s	62 ms	0.000	1.02 s
Docs Landing	1.35 s	0.56 s	148 ms	0.001	1.90 s
Contribute to Kestra (simple docs)	0.92 s	0.61 s	234 ms	0.002	0.88 s
Flow (full featured docs)	1.46 s	0.54 s	142 ms	0.000	1.35 s
Blog Index	1.81 s	0.54 s	33 ms	0.001	3.63 s
Blog Post (sample)	2.32 s	0.64 s	46 ms	0.000	0.97 s
VS Page (sample)	1.04 s	0.69 s	106 ms	0.000	0.84 s
Plugins Landing	1.12 s	0.65 s	108 ms	0.000	1.07 s
Plugin Page (sample)	1.01 s	0.71 s	55 ms	0.000	1.02 s
Plugin Debug Page (sample)	1.07 s	0.59 s	284 ms	0.000	1.13 s
Plugin Debug Return Page (sample)	1.04 s	0.53 s	294 ms	0.000	1.69 s
Blueprints Landing	2.56 s	1.06 s	124 ms	0.000	1.33 s
Blueprint Audit Logs CSV Export	1.11 s	0.75 s	321 ms	0.000	1.63 s

Legend

🟢 improved  ·  🔻 regressed  ·  (blank) no significant change
Score threshold: ±10 pts  ·  Metric threshold: ±30% of baseline

Median of repeated runs: Home x5, About Us x3, Docs Landing x5, Flow (full featured docs) x3, Plugins Landing x3, Blueprints Landing x3. A single run of these swings 20+ points between runners.
The sample is measured across 4 parallel runners, so each page carries its own CPU index (Lighthouse's benchmarkIndex). Lighthouse does not normalise for host CPU, so a page's deltas are hidden when its runner differs from the baseline's by more than 10%.

View full Lighthouse HTML report for a page

Full per-page Lighthouse Results (LHR) are attached as the lhr-reports-shard-* artifacts on this run. Download and unzip one, then open https://googlechrome.github.io/lighthouse/viewer/ and drop the <page>-lhr.json file into the page to see every audit, opportunity, and diagnostic.

[iitzIrFan]

Verified locally against the branch on a dev server: all 38 /orchestration/<slug> pages now render a docs-card link that returns 200 with no redirect. The five formerly broken ones (duckdb, postgres, snowflake, sql-server, microsoft-fabric) resolve to plugin-jdbc-duckdb, plugin-jdbc-postgres, plugin-jdbc-snowflake, plugin-jdbc-sqlserver and plugin-microsoft-fabric. Terraform, gemini and netbox are unchanged, and the old guesses /plugins/plugin-jdbc and /plugins/plugin-microsoft still 301, so the premise holds.

This is "PR 2" of #5611. Could you add Part of #5611 to the description? Parts 1 and 3 are still open, so it should not close the issue.

Two nits and one suggestion inline. None blocking.

FYI, unrelated to this change: docker.yaml declares io.kestra.plugin.docker.Build, which the catalog no longer has (it is io.kestra.plugin.docker.cli.Build now). Docker is the one page that hits the fallback branch. The link still works, so I will file it separately.

[iitzIrFan]

nit: this line is not formatted per the repo's prettier config. main is clean, so this PR introduces the drift. CI only runs oxlint and astro check, which is why it passed. npm run format wraps it.

[iitzIrFan]

nit: canonicalPluginUrl only ever yields /plugins/... paths, so this guard is redundant. A plain canonicalTaskUrl ? ... : fallback reads the same.

More broadly, the repo keeps plugin URL logic in src/utils/plugins/ with unit tests, and canonicalUrl.ts already has canonicalPluginPath computing exactly the plugin page path. A small buildPluginPageUrls(classes) next to buildTaskUrls would keep this split/slice/join out of the page and give it a test. Happy to leave as is for a one-line fix.

[iitzIrFan]

suggestion: slice(0, 3) drops the subgroup segment. 22 of the 38 tools live in multi-subgroup plugins, so BigQuery, Pub/Sub, GCS, Dataproc and Vertex AI all land on the generic /plugins/plugin-gcp root, while the catalog gives /plugins/plugin-gcp/google-cloud-bigquery, which resolves 200. Dropping only the last segment instead would link each tool to its most specific page for free:

canonicalTaskUrl.split("/").slice(0, -1).join("/")

Not a regression versus main, so your call on whether the plugin root is the intended landing page.