Bug: `pending` status not handled, causing premature success when jobs wait for runners

[JonoRicci]

This action is really useful for us, but we have a situation that occassionally happens in our GitHub Actions workflow where some jobs can be in a pending status waiting on our self-hosted runners becoming available. When this happens, the allcheckspassed action doesn't seem to recognise these and considers all checks to have passed prematurely and ends, before our runner has picked up the pending job.

Current Behaviour

In the GitHub API documentation I can see these values for check run status:

• queued
• in_progress
• completed
• waiting
• requested
• pending

In src/checks/checksConstants.ts:

export const checkStatus = {
  QUEUED: "queued",
  IN_PROGRESS: "in_progress",
  COMPLETED: "completed",
  WAITING: "waiting",
};

In src/checks/checks.ts:

let inProgressQueuedWaiting = [
  checkStatus.IN_PROGRESS,
  checkStatus.QUEUED,
  checkStatus.WAITING,
];

The pending (and requested) statuses are missing, so I suspect checks in these status are not being treated as "in progress".

It may be they have been left out here on purpose for some reason, otherwise hopefully we can add the pending status in please.

Proposed Behaviour

1. Add pending (and maybe requested as well?) to src/checks/checksConstants.ts:

export const checkStatus = {
  QUEUED: "queued",
  IN_PROGRESS: "in_progress",
  COMPLETED: "completed",
  WAITING: "waiting",
  PENDING: "pending",      // add
  REQUESTED: "requested",  // add
};

2. Include in src/checks/checks.ts:

let inProgressQueuedWaiting = [
  checkStatus.IN_PROGRESS,
  checkStatus.QUEUED,
  checkStatus.WAITING,
  checkStatus.PENDING,    // add
  checkStatus.REQUESTED,  // add
];

[wechuli]

Thanks @JonoRicci , yeah pending should definitely be included in that (possible requested as well). I have merged #98, will cut a new release for it shortly. That said, in your case, I don't believe adding pending might actually solve the problem. The reason I say that is that if a job is waiting for a self-hosted runner, its status should be queued not pending. I believe the only way to get a check to be in pending is if the job is waiting for a concurrency group.

So the action relies entirely on what the API is providing to it, if the job has not yet been created , which might be possible because of the workflow configuration or perhaps an external process hasn't run, the action won't see it.

[JonoRicci]

Hey @wechuli, thanks for merging and the prompt release! I tested the new version in our workflow this morning and it looks like it is working successfully so far 🤞

Just to confirm, yes our job has a concurrency group it is waiting on, I think I may have misunderstood what was going on when writing the issue.

Thanks again for your help, cheers.