[wylswz]

part of #45070

Summary

• main-ci.yml only triggers on main, so PRs targeting lts/* currently only run the cherry-pick provenance check — no tests or type checks.
• Add a standalone .github/workflows/lts-ci.yml for PRs to lts/**. A check-changes job (dorny/paths-filter) gates each suite on changed paths:
  • API Unit Tests (api/**, Makefile, dev/pyrefly-check-local): same unit commands as this branch's api-tests.yml; integration tests and coverage upload are not included.
  • API Type Check (same paths): make type-check-core (pyrefly + mypy), same as the Run Type Checks step in style.yml.
  • Web Tests (web/**, packages/**, pnpm files): calls the existing reusable web-tests.yml.
  • Dify Agent Tests (dify-agent/**): calls the existing reusable dify-agent-tests.yml.
• This is an LTS-only CI change with no counterpart on main, so the provenance check is expected to fail and needs an admin override.

Known baseline failure (not caused by this PR)

• API Unit Tests currently fails on lts/1.17.x: api/uv.lock pins aiohttp 3.14.4, which imports yarl.query_to_pairs, but the lock pins yarl 1.23.0, which doesn't have it. Anything importing fastopenapi → aiohttp fails (swagger spec tests, test_app_factory, controller test collection). Keeping this PR open until that is fixed on the branch.

Test plan

• actionlint clean (only the known depot-ubuntu-24.04 custom runner label warning)
• make type-check-core passes locally on a clean lts/1.17.x checkout (pyrefly ×3 configs + mypy: no issues in 1796 files)
• LTS CI / API Unit Tests green after the aiohttp/yarl lock fix lands
• Other LTS CI jobs green on this PR

Generated with Devin

[tech00exploere]

I noticed a potential compatibility issue with the type-checking step in the new LTS CI workflow.

the workflow currently invokes make type-check-core. If this target is not defined in the lts/1.13.x branch, the type-checking job will fail before it can perform any checks on that branch.
Could we make the type-checking command branch-compatible? For example, we could use the appropriate existing target for each LTS branch or introduce a small compatibility mechanism that selects the supported target.

I'd suggest verifying the target names across lts/1.13.x, lts/1.17.x, and main before finalizing the workflow, so the new CI coverage works consistently across supported branches.

[wylswz]

I noticed a potential compatibility issue with the type-checking step in the new LTS CI workflow.

the workflow currently invokes make type-check-core. If this target is not defined in the lts/1.13.x branch, the type-checking job will fail before it can perform any checks on that branch. Could we make the type-checking command branch-compatible? For example, we could use the appropriate existing target for each LTS branch or introduce a small compatibility mechanism that selects the supported target.

I'd suggest verifying the target names across lts/1.13.x, lts/1.17.x, and main before finalizing the workflow, so the new CI coverage works consistently across supported branches.

You are correct, but lts/1.13.x has gone too far and is more difficult to fix. We'll do that in separated PR.

[wylswz]

I noticed a potential compatibility issue with the type-checking step in the new LTS CI workflow.

the workflow currently invokes make type-check-core. If this target is not defined in the lts/1.13.x branch, the type-checking job will fail before it can perform any checks on that branch. Could we make the type-checking command branch-compatible? For example, we could use the appropriate existing target for each LTS branch or introduce a small compatibility mechanism that selects the supported target.

I'd suggest verifying the target names across lts/1.13.x, lts/1.17.x, and main before finalizing the workflow, so the new CI coverage works consistently across supported branches.

You are correct, but lts/1.13.x has gone too far and is more difficult to fix. We'll do that in separated PR.