ci: make scheduled branch matrix dynamic

[kolyshkin]

Follow-up to #5393 (review comment).

The list of branches to run periodical CI on was hardcoded, meaning it had to be manually updated on every minor release (add the new release branch, drop the one that falls out of support per RELEASES.md), and would silently keep testing unsupported branches if we forgot.

Instead, a prepare job lists the repo branches via the API and picks the three most recent release-X.Y ones (latest, latest-1, latest-2), plus main, feeding them into the matrix via fromJSON.

Running the same selection logic against the current branch list of this repo yields ["main", "release-1.5", "release-1.4", "release-1.3"], i.e. exactly the list that was hardcoded before, so there is no behavior change today.

🤖 Generated with Claude Code

[kolyshkin]

Alas no way to test this until we merge.

[kolyshkin]

Would be nice to have before 1.6 since the matrix will change and we'll forget again (see #5393 as an example of how we forgot).

[lifubang]

LGTM
One edge case worth flagging: the selection is based on branch existence, whereas the support policy in RELEASES.md is about released versions. Since a new release branch is created at rc.1 (feature freeze, ~2 months before the .0 release), the moment release-1.6 is created the matrix becomes [main, release-1.6, release-1.5, release-1.4] and release-1.3 drops out of scheduled CI, even though 1.3 is still a supported release (latest-2) until 1.6.0 actually ships.

The impact is limited: only the oldest branch loses scheduled coverage for that ~2-month window (it still gets CI on every PR and via workflow_dispatch), and testing the upcoming rc branch is arguably more valuable anyway, so this may be perfectly fine. If we ever want the matrix to track the support policy exactly, we could exclude branches whose latest tag is still -rc.

Not blocking, just making sure this is a conscious decision.

[kolyshkin]

LGTM One edge case worth flagging: the selection is based on branch existence, whereas the support policy in RELEASES.md is about released versions. Since a new release branch is created at rc.1 (feature freeze, ~2 months before the .0 release), the moment release-1.6 is created the matrix becomes [main, release-1.6, release-1.5, release-1.4] and release-1.3 drops out of scheduled CI, even though 1.3 is still a supported release (latest-2) until 1.6.0 actually ships.

The impact is limited: only the oldest branch loses scheduled coverage for that ~2-month window (it still gets CI on every PR and via workflow_dispatch), and testing the upcoming rc branch is arguably more valuable anyway, so this may be perfectly fine. If we ever want the matrix to track the support policy exactly, we could exclude branches whose latest tag is still -rc.

Not blocking, just making sure this is a conscious decision.

You're right about it. Three ways to solve it:

1. add a logic to check for released (non-rc) tag -- too complex;
2. switch to testing 4 rather than 3 last branches -- easy but we'll end up testing an unsupported branch;
3. do nothing (and have a gap).

I'm choosing option 3 -- after all, we did not have this testing at all for quite some time (#5393) and no one noticed.

[kolyshkin]

(oh, and I've added a comment to the job explaining that we lose the oldest branch for some time)