Skip to content

ci(unit-tests): a KTLO or experimental leg that fails at job level, such as a lost runner, still fails Required checks passed #1738

Closed

Description

@JarryShaw

Describe the bug
A KTLO or experimental leg can still block a PR. Those legs carry only step-level continue-on-error (unit-tests.yml:158, :162, :209, :235, :243). If the job itself fails rather than a step, nothing contains the failure. test then reports failure, and Required checks passed fails.

Reproduction
On #1734 (ba67ef70e, run 38599394443), job 115975614204 Python graalpy-25.4 (experimental) lost its runner 18 minutes into Run unit tests (cap 25):

17:17:32Z ##[error]The runner has received a shutdown signal. ...
17:17:37Z ##[error]The operation was canceled.

Job 115994929719 Required checks passed then printed test: failure and result was 'failure'; accepted here: success, and exited 1. Every non-experimental leg passed.

Expected behavior
A KTLO or experimental leg never fails the required context, whatever ends it: a step failure, a step cap, a job cap or a lost runner. The fix needs a source for how needs.<job>.result treats a matrix leg under job-level continue-on-error.

Additional context
This edits the same file as #1732, so it is blocked until #1732's PR merges. The failed jobs on #1734 have been re-run.

Activity

  1. added
    ciPull requests that change CI or workflow configuration (ci: subject prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 14, 2026
  2. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    Narrowed. On #1732 the owner chose to move the experimental legs into a job of their own that nothing gating waits on, and that work is in progress. Once it merges, a lost runner on an experimental leg can no longer block. What remains here is the KTLO half: KTLO legs stay in test, so a job-level failure on one still fails Required checks passed. This stays blocked until #1732 merges.

  3. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    #1742 has merged. The experimental half is fixed: those legs now run in experimental.yml, which nothing gates on. What remains is the KTLO half. KTLO legs still live in test, which required-checks (unit-tests.yml:1885) and unittest-ordering both needs:. A job-level failure on one, such as a lost runner or the job cap, therefore still fails Required checks passed.

    Option Effect
    A. Move the KTLO legs (unit, integration, parity) into jobs of their own that nothing gating needs:, as #1742 did No KTLO failure can block a PR. KTLO keeps reporting as before
    B. Keep them in test, but add job-level continue-on-error Only works if needs.test.result then reads success. That needs a source and a test run, and the check would still show red
    C. Leave it as is Rare blocks, fixed by a re-run

    Recommendation: A. It is the same shape as the experimental fix, and KTLO legs are non-blocking by design (#1633).

  4. added
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 14, 2026
  5. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    A

  6. JarryShaw commented on Oct 14, 2026

    @JarryShaw
    OwnerAuthor

    Recorded: A. The KTLO legs of test, integration and pypcap-parity move into jobs of their own, which neither required-checks nor unittest-ordering needs:. They keep their check names, their warning-level annotations and their KTLO summaries. A worker is on it.

  7. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    needs: decisionWaiting on the maintainer to decide — not blocked by other work
    on Oct 14, 2026
  8. moved this from Blocked to WIP in PyPCAPKiton Oct 14, 2026
  9. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ciPull requests that change CI or workflow configuration (ci: subject prefix)

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions