Add a wait-for-completion option.

[VincentLanglet]

Hi @benc-uk,

There is a fork of your action (aurelien-baudet/workflow-dispatch) which is providing a wait-for-completion action:
https://github.com/aurelien-baudet/workflow-dispatch#wait-for-completion

Looking at github history, it doesn't require a lot of commit https://github.com/aurelien-baudet/workflow-dispatch/commits/master/

But this fork is not maintained anymore (cf the-actions-org#16 (comment))
Would you be interested adding such feature here ?

[aurelien-baudet]

Repository transferred to https://github.com/the-actions-org/workflow-dispatch

[mjeco-prgs]

@aurelien-baudet Why did you transfer the repository? Now all existing workflows using your repo will fail.

[aurelien-baudet]

Because I do not have time to maintain so there is an organization that has been created with several maintainers. This is not what is explained by github. It was stipulated that all previous links to my repository will be forwarded automatically to the new one. So it should still work.

…

On Mon, May 27, 2024 at 11:59 AM Michal Jeco ***@***.***> wrote: @aurelien-baudet <https://github.com/aurelien-baudet> Why did you transfer the repository? Now all existing workflows using your repo will fail. — Reply to this email directly, view it on GitHub <#73 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE5R46DT27I5L4OH5B6PSTZELRX7AVCNFSM6AAAAABHWPPVEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSHA3TSMBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[thiagomarinho]

@aurelien-baudet I think Github might need to be more explicit about the consequences for moving an action from one org to another; this change did break workflows in the company I work on, so we had to release new reusable workflows updating the path where the action is now.

To make it a non-breaking change, maybe you could recreate a fork in your personal account, keeping all the existing tags, then add a message in the README about where the action will be developed from now on.

With that said, I understand you don’t have time anymore to maintain your fork, and I really appreciate the effort you’ve put into this action; it was and is really helpful for us.

[VincentLanglet]

Hi @mjeco-prgs @thiagomarinho
This is discussion is kinda off topic the feature request I opened.
I recommend you to open an issue on the fork and not in this, unrelated, repository.

[benc-uk]

What the hell is going on here?!

[mjeco-prgs]

@benc-uk In short, your action was forked by @aurelien-baudet who added a nice wait-for-completion feature. Problem is, this fork is not being maintained anymore. The ask was, if you would add wait-for-completion to your action so the fork can be deprecated.

[benc-uk]

Thanks @mjeco-prgs I think I've caught up 😁

OK I've spent a few hours looking into this and trying to implement the wait for completion feature.

It's really not as simple as it first appears, thanks to the GitHub API. In short the workflow_dispatch API does not return the run-id of the run it triggers. To me this seems an is absolutely insane decision!

So you have to resort to weird & unhappy workarounds, such as querying workflow the runs and then enumerate the results to try to guess/find which run might be the one you've triggered. I looked @aurelien-baudet's code and it relies on checking timestamps and other methods, which is probably the best you can do, but I'm not happy with this approach.

There's still a good chance that something else kicks off a workflow at this time and you get yourself in a mess. That's not to mention how unreliable clocks and timestamps can be.

I've also looked at waiting a few seconds and checking the list of runs, and grabbing the first entry - but again I have no guarantee that it's actually the run we just triggered.

I'll keep investigating, but the GitHub API is a disaster in many places and I'd rather not implement something that "probably should work but I can't guarantee it won't do something weird one day"

[mjeco-prgs]

@benc-uk Yes, I have seen this race condition behaviour with @aurelien-baudet's action. When I have multiple triggers of the same workflow, the action sometimes incorrectly picks up the status and marks failed workflows as successful. As you've mentioned, there is no guarantee to check the correct workflow run as github does not return the run ID.

[benc-uk]

Interesting, good to know my hunch that this could happen wasn't just worrying about an extreme edge case

I'll have a look in the GitHub actions discussions and see if anyone has a solution or at least we request the workflow_dispatch API gets updated, but I don't see that ever happening TBH

As I said, I really don't want to implement this unless we have complete confidence in its operation

[pdmtt]

@benc-uk, I've been looking for a reliable solution for this problem too and found out it's possible to inject a value as the workflow run's name when dispatching.

The con is that people would need to modify the dispatchable workflow to accept this input.

Sharing in case it helps:
https://github.com/orgs/community/discussions/9752