remorses / actions-cli

Monitor your GitHub Actions in real time from the command line

𝕏

actions-cli's Issues

manual token?

Is there a way to set the token manually? I develop on a remote server, so localhost doesn't work for me.

Request: low permission login option

Currently the login process grants permission to "read and write all public and private repository data" -- which is more than I'm willing to give, especially considering I only want to check on public projects.

Can we get a more limited option for permissions granting?

Error: cannot parse github url master

After installing and performing a login, I execute actions-cli and I see:

Error: cannot parse github url master

Unable to watch progress on manually-triggered workflows

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.)

Not working for organization repositories using built in login flow, HttpError: Not Found

✗ actions-cli login
login at http://localhost:61580
Token Saved
Run actions-cli to see the actions status for the current commit

✗ actions-cli
ℹ getting last commit sha
⠼ fetching state for sha 'b91e1fd'
HttpError: Not Found

Seeing old complete runs rather than runs in progress, when a run hasn't started yet

I have a script that pushes a tag, and then immediately calls actions-cli to watch the deploy workflow triggered on: create of that tag.

Right now, I need to insert a sleep in my script, because without it, actions-cli just finds the newest existing run (the one from the last deploy), shows it, and exits.

Although my tag has already been pushed, the relevant workflow-run gets created asynchronously on Github's side, and it seemingly takes a few seconds. So if I invoke actions-cli right away, the new run isn't available yet. Instead, it just sees the old runs, and assumes I wanted to see the newest of those.

But of course, I actually want to see the new run; and if hasn't been created yet, I want actions-cli to wait around until it does get created, and then show its progress.

Proposed fix

• Add a timestamp-valued switch to actions-cli, which will tell it to ignore or avoid matching any workflow-runs that were created before the passed timestamp.
• Add a boolean switch, to tell actions-cli that if it fails to discover any non-ignored runs (as could happen with the above time-filter in place), it should not exit, but rather should poll the workflow-runs API endpoint until it does successfully find a workflow run that passes the filter.

With these two switches together, I wouldn't need the sleep in my script; instead, I could run e.g. actions-cli --runs-since=... --block-until-found, and it would just sit there until a new workflow-run starts, at which point it would then start logging the progress of that workflow-run.