Turnstyle Not Waiting

[alexyao2015]

Hi thanks for creating this action! I seem to be having an issue implementing it as it seems that turnstyle does not wait no matter what I try. Here are two workflow runs and the workflow file. I've tried various different tests to try getting Turnstyle to operate including trying both jobs and steps to no avail. As you can see #70 failed due to #69 running before it.

Any ideas on this issue?

[beckermr]

@softprops Something is definitely not working here. I think the workflow is not finding previosu runs.

[beckermr]

It appears the status option for the github api endpoint (https://docs.github.com/en/rest/reference/actions#list-workflow-runs-for-a-repository) is not working.

[GMNGeoffrey]

I recently had two runs clobber each other https://github.com/google/llvm-bazel/runs/2006744030 and https://github.com/google/llvm-bazel/runs/2006723320 when they were started within a few seconds. I'd expect turnstyle to have waited here.

[EKami]

Yep, not working on my side either =/

[sandyscoffable]

😢 Not working here either

[DanRunfola]

Same :(

Something appears to have changed, or is only intermittently working, on the github API side.

[beckermr]

It is the GitHub API. Some of the query parameters for GitHub actions are not working. I don't have a fix for this one, but I wrote my own version here: https://github.com/beckermr/turnstyle-python

[beckermr]

It is the status parameter to this endpoint: https://docs.github.com/en/rest/reference/actions#workflow-runs

[beckermr]

I had to switch to looking to at most the last 500 workflow runs: https://github.com/beckermr/turnstyle-python/blob/main/turnstyle.py#L56

[opike]

In case it helps anyone, it wasn't working when I was using @v1 and then it started working after I switched to @master.

[opike]

Did some more research and v1 is the top of master so it wouldn't make any sense for it to make a difference. I switched back to @v1 and now that's working as well. My current prevailing theory is that github fixed the api while I was troubleshooting :)

[softprops]

Hi folks. Are you still seeing this issue?

[EKami]

@softprops Yep, still not working on my side on either v1 or master

[opike]

It was working for a bit for me, and now recently I started seeing the problem again.

[vigneshmsft]

I have raised a PR(#31) which will find both in_progress and queued workflow runs, which I believe will solve this issue. You are also free to use my fork to test it.

[opike]

the PR from @vigneshmsft looks to have fixed the problem for me

[mastercoms]

Doesn't fix the issue for me.

[opike]

Now I'm seeing the same 'not waiting' problem with the PR from @vigneshmsft. Anyone else having the same experience?

[nilsbillo]

Got this reply from github on 2022-04-14

The underlying issue was with Elastic search but it has been fixed, but we will not see new results for filtered lists until we have a new index.
To set expectations, this could be a couple of days. In this case, you would see the most recent runs if you remove the filter.
Elastic search backs filters in our API and UI. So unfiltered workflow runs lists will be correct, but filtered lists will be stale.
I hope this helps in the interim. I'll let you know when the re-index is complete, so you can search by filters again.

Have the same issue with another action implementing the same thing and seems this action has the same problem. Still waiting for the reindex to be completed.....

[opike]

In case some folks weren't aware, github added a concurrency setting last year: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency

However the behavior doesn't mimc exactly that of turnstyle. Rather than canceling the most recent workflow run, it either A) cancels the older workflow run and the new workflow run becomes active, or B) puts the new workflow run in a pending state and it will begin execution after the older workflow run completes.

[softprops]

I should at a mention of that to the readme. where there is a native solution and that works for you, you'll want to prefer that.

Other draw backs of GitHubs newer concurrency control feature is the syncing point is at the workflow level and not the job level meaning, if you have more than one workflow run queued up, github actions native concurrency will not allow those workflow runs to make process up until the sync point. Neing able to make process is often useful as you can be running unit tests and building artifacts while you wait for the previous run to finish up its deployment.

[opike]

BTW, there is also a job level concurrency setting: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency

But as with the workflow level setting, perhaps the behavior doesn't match that which turnstyle provides. I'm not sure since we've only been using workflow level concurrency.

[sekhavati]

I'm also having similar issues to folks above. In our case we were guarding against multiple deploys to AWS happening concurrently but the action doesn't seem to be working as intended unfortunately