fix: include queued runs in previousRun

[aslafy-z]

I'm running self-hosted runners. Sometimes, I see this action releasing it's lock wrongly because a earlier run goes into the queued status. Sadly, I did not found any way to filter on the status other than client-side.

[softprops]

If this run, the one querying for a prior active run, is in progress how would it be possible for a previous run to be queued?

In a build queue it's first in first out so if the previous run was queued that implies the current run has not yet started.

[ghost]

Hi, at my team we've hit this issue while assessing this action. We used the following workflow definition, pretty much emulating the one we have in production:

name: Deployment Lock

on:
  push:
    branches:
      - master

jobs:
  test-A:
    runs-on: ubuntu-latest
    steps:
      - name: Test A
        run: echo "A is healthy and productive"

  test-B:
    runs-on: ubuntu-latest
    steps:
      - name: Test B
        run: echo "B is healthy and productive"

  turnstyle:
    runs-on: ubuntu-latest
    steps:
      - name: Turnstyle
        uses: softprops/turnstyle@v1
        with:
          poll-interval-seconds: 10
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  provision:
    needs: [test-A, test-B, turnstyle]
    runs-on: ubuntu-latest
    steps:
      - name: Provision Infrastructure
        run: date && sleep 60 && echo "Your infrastructure is ready and looking forward for you to maintain it ;)" && date

  deploy-A:
    needs: provision
    runs-on: ubuntu-latest
    steps:
      - name: Deploy A
        run: date && sleep 30 && echo "A is running its latest version!" && date

  deploy-B:
    needs: provision
    runs-on: ubuntu-latest
    steps:
      - name: Deploy B
        run: date && sleep 30 && echo "B is running its latest version!" && date

We triggered two workflows, the second starting while the other was running the provision job. When the provision job of the first workflow finished then the turnstyle job of the second stopped waiting and the provision job of the second workflow started, almost at the same time the deploy-A and deploy-B jobs of the first workflow started.

We did the same test using this PR fork and it worked as expected. The turnstyle job of the second workflow waited until all jobs of the first workflow completed, including deploy-A and deploy-B.

Our theory is that the workflow run goes back to queued status in between jobs (when provision finishes and while deploy-A and deploy-B are started).

[ltamrazov]

Wonder if this is the same issue as we are experiencing in #27