Skip to content

fix(lgtm): keep evaluating the remaining pull requests when one evaluation fails - #375

Merged
jeefy merged 1 commit into
cncf:mainfrom
jeefy:fix/lgtm-cron-continue
Oct 8, 2026
Merged

jeefy merged 1 commit into
cncf:mainfrom
jeefy:fix/lgtm-cron-continue

Conversation

@jeefy

@jeefy jeefy commented Oct 8, 2026

Copy link
Copy Markdown
Member

Bug. The lgtm cron is documented (doc comment in src/cronJobs/lgtm.ts, docs/automatic-merging.md) to attempt every eligible pull request and fail at the end listing the failures. That held for merges GitHub refused, but an evaluation that threw for one pull request (e.g. a 500 re-reading it) made the page throw error processing pr: ..., so later pull requests on later pages were never evaluated. No commit, comment or doc says the fail-fast was intended (it dates from the 2020 "Catch error cases" commit; #335 only pinned it with a test).

Fix. A throwing evaluation is logged with core.error as could not evaluate pr #<n>: <error> and collected with the refused merges; the job continues with the remaining pull requests and pages, then fails with the existing summary, e.g. 1 pull request(s) could not be merged: #7 (could not evaluate: HttpError: ...). A listing that cannot be read still stops the job (could not get PRs).

Tests changed (they pinned the old behaviour).

  • __tests__/cronJobTest/lgtm.test.ts: "fails the run when evaluating a pr throws" replaced by two cases: a sibling on the same page is still merged and the run fails naming the broken PR; paging continues after the broken PR and the summary names both an evaluation failure and a refused merge.
  • __tests__/bundle/cronLgtmFailureArms.test.ts (test(bundle): drive the lgtm cron's listing-500, closed-pr and evaluation-throw arms through dist/index.js #335): "evaluation throw ... stops paging" now asserts page 2 is listed, its PR is merged, and the run fails naming #2.

Docs: docs/cron-jobs.md, docs/automatic-merging.md describe the evaluation-failure arm. dist/index.js regenerated with npm run all.

Verified locally: npm run all (1847 tests), npm run test:coverage (thresholds pass), second npm run pack leaves dist/ clean, npm run test:coverage:e2e (214 tests; src/cronJobs/lgtm.ts 100 %).

…ation fails

The lgtm cron's doc comment and docs/automatic-merging.md say every
eligible pull request is attempted and the run fails at the end listing
the failures. That held for merges GitHub refused, but an evaluation that
threw (for example a 500 re-reading one pull request) made the page throw
`error processing pr: ...`, so the remaining pages were never evaluated.

A throwing evaluation is now logged with core.error as
`could not evaluate pr #<n>: <error>` and collected with the refused
merges; the job goes on with the remaining pull requests and pages and
fails at the end with the existing summary, e.g.
`1 pull request(s) could not be merged: cncf#7 (could not evaluate: HttpError: ...)`.
A listing of the open pull requests that cannot be read still stops the
job (`could not get PRs`).

Tests: the unit case and the bundle case (cncf#335) that pinned the
fail-fast behaviour now assert that a later pull request (same page, and
the next page) is still evaluated and merged and that the run fails
naming the broken one. docs/cron-jobs.md and docs/automatic-merging.md
describe the evaluation-failure arm.

Signed-off-by: Jeffrey Sica <me@jeefy.dev>
@jeefy
jeefy requested a review from jpmcb as a code owner October 8, 2026 01:17
@jeefy
jeefy merged commit 4fb1782 into cncf:main Oct 8, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant