GitHub Runner Scaler: Fix/7969 respect paging for jobs

[jangraevell-pd]

Fixes the GitHub Runner scaler's 100-job hard limit described in #7969.

getWorkflowRunJobs only ever requested a single page (per_page=100) of a
workflow run's jobs and never followed pagination. For a run with more than
100 jobs, the still-queued/in-progress jobs beyond the 100th were silently
never counted towards the scaler's queue length, causing scaling to stop as
soon as the first 100 jobs of a run finished.

Changes:

• getWorkflowRunJobs now loops through pages (&page=N), accumulating jobs until a page returns fewer than githubJobsPerPage (100) jobs.
• Extracted the per-page fetch/ETag/previousJobs-cache handling into a new fetchWorkflowRunJobsPage(ctx, workflowRunID, repoName, page) helper.
• Added a regression test (TestNewGitHubRunnerScaler_QueueLength_SingleRepo_150Jobs_100Completed) simulating a 150-job run (100 completed on page 1, 50 still queued on page 2) with a page-aware mock server, asserting the correct queue length of 50.
• Added a Changelog entry.

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Unchecked items are not applicable (no new scaler, no scaler schema/metadata changes, no Helm/manifest or docs/UX changes).

Fixes #7969

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[rickbrouwer]

Thanks for the fix.

I think there's an issue: when enableEtags is on, a 304 on page 1 returns the cached combined job list, but page 1's ETag says nothing about later pages. Once the first 100 jobs are completed, page 1 stops changing while jobs on page 2+ do, so the queue length freezes until the run finishes. Caching per page (keying previousJobs by URL instead of repo name) would solve this and would also make the ETags for pages beyond the first actually useful, since right now a 304 there always leads to dropping the etag and refetching. While you're at it, please use the new githubJobsPerPage constant in the URL instead of the hardcoded per_page=100, and update the test comment that says it's "expected to fail until pagination is implemented", since the fix now lives in the same PR.

[jangraevell-pd]

Will have a look this evening. Your annotation seems valid.

[jangraevell-pd]

@rickbrouwer how do we continue from here? Do I need to do something?

[rickbrouwer]

Can you check this? With enableEtags, a 304 on page 1 returns cached=true and page 2 is never fetched, but ETags are per page. Once page 1 is fully completed it stops changing, so the queue length freezes. Must the cache be per page instead? Do you know this?