Unable to watch progress on manually-triggered workflows

[tsutsu]

We have a workflow that is manually triggered by a CLI command. The CLI command uses cURL to create a workflow_dispatch event, which in turn triggers an Actions workflow that is triggered on: workflow_dispatch.

The repo does not have any new commit or tag associated with this workflow. The workflow is running against the "existing" repo, rather than because something in the repo changed.

actions-cli seems to discover these workflow-runs successfully — but it doesn't understand how to deal with the fact that there are a large number of them associated with the same "existing" commit. So rather than the currently-executing run, actions-cli shows me a random old already-complete run of the same workflow.

Potential fixes

• You could allow the user to directly pass a workflow_id; the tool could then make an API call to /repos/{repo}/actions/workflows/{workflow_id}/runs, and select the newest run of the returned set (i.e. the one with the highest run_number.)

• You could allow the user to directly pass run_id. The user would have to get that run_id from somewhere (maybe making Github API calls themselves); but, presuming they did (or some script did it for them), then they'd be assured to be targeting exactly the run they want to watch the progress of.

(Both of these cases would also be made even more useful by the --block-until-found switch I proposed in #8.)

[remorses]

As I said in #8, this cli only supports seeing actions on commits

I can try to work on this if I find some time