Github Actions

[agzam]

For a very long time I've been contemplating the idea of writing a package that lets you observe Github Actions logs without leaving Emacs.

Using gh (cmd-line tool) it is almost trivial to figure out:

• Current Github repo name
• Current branch of the project you're currently in and associated Github workflow
• You can check the status of the run (ongoing, finished, failed)
• You can extract logs for the run and inspect them in a log-mode buffer.

I think it would make sense to built something like that on top of this package. We can even expand it later to show the workflow in a buffer with collapsible sections (like on GitHub UI), using magit-section.el.

wdyt, @armindarvish ?

[armindarvish]

I haven't used github actions. I first need to learn about that and then figure out how to implement it here with a good UI. I can come back to it later. In the meanwhile if you can provide more context and example of how you do this with gh and what are the interactive menus you would need, etc. it can help me think about what would be a good implementation.

[ParetoOptimalDev]

Something similar but not the same is that forge has an open pull request for CI build statuses:

magit/forge#586

It would be great to interact with actions from within emacs though, agreed!

[Lenbok]

A consult based interface for dispatching workflows (e.g.: gh workflow run {name} --ref {ref}) that asks for the workflow name and ref would be super!

[armindarvish]

@Lenbok I should be relatively esy to add support for this, but I looked at this in the past, and at the time it did not seem like a great fit for a consult-gh's interface. So if you can help answer some questions and elaborate on what exactly you have in mind, I can then think about how to implement it.

1- The main interface
consult-gh's interface (reading candidates from the minibuffer) is limited to showing target candidates and selecting them with embark adding some additional actions. In case of workflows, what would be the list of candidates? what would be the default action (runing the workflow or seeing a summary, ...)?

2- what happens in a default directory that is not a github repo?
So far, consult-gh's main goal has been to allow simple viewing of things (repos, issues, etc.) similar to viewing any repository in the browser and not so much working directly interacting with repos (like you would do on a local clone). For the latter we would need a very different interface like magit and forge and those are better tools for that purpose. In other words, consult-gh commands can be run from any directory (does not have to be inside a repo) to view any repositories (or issues,...).
That means for workflows, we would have to do something similar to what we do now for issues, the user has to first search/select a repo and then can see its workflows (similar to opening Actions page on github webpage). But what is the use-case for seeing workflows in a repository, you are not activley working on? Is the interest in seeing the summary, or what?
If the interest is only in runing actions on repos you are actively working on (like the example you mentioned above), I think that is a better fit for magit/forge, because their interface allows runing more complex commands compared to minibuffer interface.