Waiting for a branch to finish all checks before running

[te-online]

Thanks a lot for publishing this action!

Can this action be used to wait for actions on one branch, so they're only ever run sequentially? I tried this config, but it doesn't seem to find other running checks (maybe because they're from another commit?).

- uses: jitterbit/await-check-suites@v1
  with:
    # The commit's ref (can be a SHA, branch name, or a tag name).
    # Default: ${{ github.sha }}
    ref: 'dev'

    # Wait for a check suite to be created if none exist.
    # This is important to protect against race conditions
    # if you know a check suite should exist on the `ref`'s commit.
    # Default: true
    waitForACheckSuite: false

    # Number of seconds to wait before timing out.
    timeoutSeconds: 3600

    # Fail step if any of the check suites complete with a conclusion other than 'success'.
    # Default: true
    failStepIfUnsuccessful: false

I pushed to dev in short sequence and two checks were running. Result:

Run jitterbit/await-check-suites@v1
No check suites (excluding this one) exist for this commit.
Conclusion: success

[sean-krail]

Hey @te-online, thanks for using the action! Sorry for the late reply. Not sure why I didn't get a notification...

That's exactly the problem this action is meant to solve. In fact there's an automated test that checks for this exact use case (https://github.com/jitterbit/await-check-suites/blob/master/.github/workflows/test.yml#L78-L118).

Not sure why it isn't working for you. Some questions I have for you that may seem obvious:

1. Is the dev branch on the same repo that is running the action?
2. Can you verify that there are status checks on this branch at the time it is run? You may want to try setting waitForACheckSuite to true. There's a slight delay in time between when the commit gets pushed and when the status checks are created.

One way you can test #2 is by running the following curl command on your repo/branch with your own personal access token set in $GITHUB_PAT:

GITHUB_REPO='<repo here>' # e.g., jitterbit/await-check-suites
GITHUB_PAT='<personal access token here>'

curl --silent --header "Authorization: Bearer $GITHUB_PAT" --header 'Accept: application/vnd.github.antiope-preview+json' \
  "https://api.github.com/repos/$GITHUB_REPO/commits/dev/check-suites" | less

[te-online]

Thanks for getting back to me. Didn't have time to look at your answer thoroughly.

Re. 1. Yes, it's on the same repo.

I have this in the yaml-file

on:
  push:
    branches:
      - dev

But the problem might just be that I don't fully understand Github Actions, yet.

Re. 2. I'll check that out, thanks!

[te-online]

I was able to make it work more reliably 😊
Using this workflow file:

on:
  push:
    branches:
      - dev
name: Deploy dev branch
jobs:
  deploy:
    name: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: jitterbit/await-check-suites@v1
        with:
          # The commit's ref (can be a SHA, branch name, or a tag name).
          # Default: ${{ github.sha }}
          ref: 'dev'

          # Wait for a check suite to be created if none exist.
          # This is important to protect against race conditions
          # if you know a check suite should exist on the `ref`'s commit.
          # Default: true
          # waitForACheckSuite: true

          # Number of seconds to wait before timing out.
          timeoutSeconds: 15

          # Fail step if any of the check suites complete with a conclusion other than 'success'.
          # Default: true
          failStepIfUnsuccessful: false
      - uses: actions/checkout@master
      - uses: actions/setup-node@v1
...

I lowered the timeout to 15 seconds, because I realized that it's the timeout to wait for a “green light“ (in lack of a better term). If within this timeout there's still another check suite running, it's just going to fail the later test suite, which is what I expected.

However, I was still able to reproduce the race-condition (even though waitForCheckSuite is no longer set to false) that when two checks of type Run jitterbit/await-check-suites@v1 for some reason run at the very same time in two check suites triggered by dev, at first they seem to block each other from doing anything and then they both proceeded at some point. I guess this happens because none of the check-suites knows if it has priority over the other, right? But shouldn't that fail both of them? Maybe I'm missing something here 🤔

Edit: Okay, maybe I misinterpreted the timeout property... I'll keep tinkering around and will report back if I found something that works 😉

Edit 2: One thing I noticed about the URL you put in your response – if I hit this endpoint, I only ever get one check-suite, even if multiple ones are running.

[sean-krail]

when two checks of type Run jitterbit/await-check-suites@v1 for some reason run at the very same time in two check suites triggered by dev

Just to be clear about your use case, you only have this one workflow that triggers on the dev branch but you want this await-check-suites step so that you only do one deployment at a time (the deployments queue up). If this is the case, you should have waitForACheckSuite set to false and failStepIfUnsuccessful set to false (like you have it).

Edit 2: One thing I noticed about the URL you put in your response – if I hit this endpoint, I only ever get one check-suite, even if multiple ones are running.

Is this a public repo by chance?

[te-online]

Thanks so much for your response and apologies for my late reply. I have the config as you describe, but still can't make it work. The repo is private, but I can re-create this in a public repo. However, I'll need some more time to do this. Will try to get to it next week. Thanks again.

[te-online]

Okay, here's the test case: https://github.com/te-online/await-check-suites-test/actions
You can see that both runs failed, but note that await-check-suites didn't fail them and didn't seem to have done anything, although they have been running at the very same time. (Edit: They failed, because of an error in the package.json)

Thanks already for your efforts so far. I'm sorry to bother you with this, if this is just an uncovered use-case or some config error 🙈

[sean-krail]

Thanks already for your efforts so far. I'm sorry to bother you with this, if this is just an uncovered use-case or some config error 🙈

Not a problem. Thanks for using this action!

You can see that both runs failed, but note that await-check-suites didn't fail them and didn't seem to have done anything

The action (silently) failed because the ref dev doesn't exist in the repo. I created an issue to improve logging and error handling overall in this action (#2) which will make it more clear why the action failed and also make sure that the step fails when repo/ref doesn't exist. I'm going to create a dev branch in your test repo with a simple push workflow that'll sleep for 5 minutes and then pass for testing purposes. Then trigger an update in the dev branch and then master branch, just to make sure that that master branch workflow is waiting properly.

Edit: There we go. I triggered dev's push workflow (link) and master's push workflow (link) waited for it properly.

(Edit: They failed, because of an error in the package.json)

Yes, looks like it's having an issue with the lerna package.

[te-online]

The action (silently) failed because the ref dev doesn't exist in the repo.

Yeah, that was a copy and paste error on my side 😅. This issue doesn't exist on the actual repository.

Edit: There we go. I triggered dev's push workflow (link) and master's push workflow (link) waited for it properly.

That looks good, I agree :-)

However, our setup has to wait only for its own ref to finish other actions and not for other refs. I adjusted the config. A simple test went just fine. I have no idea what changed... 🎉

[sean-krail]

Awesome! So it’s working in your private repo now? If so I’ll close this ticket out.

[te-online]

I seems like it 😊 I'll keep you posted on any updates