feat: poc octo run list

[GustavEikaas]

Important

This is a draft PR
Im making this draft PR so I can get reviews/suggestions during development
I will fill out the PR template when the PR is ready for review

Resolves: #149

Describe what this PR does / why we need it

First PR in a series of PRs to add support for github actions

Does this pull request fix one issue?

Describe how you did it

Describe how to verify it

Special notes for reviews

Checklist

• Passing tests and linting standards
• Documentation updates in README.md and doc/octo.txt

Feature checklist

• Buffer
  • Expand/collapse node
  • Highlights
  • Keybindings
    • Refresh
• Workflows
  • Support multiple jobs
• Workflow job steps
  • Logs
  • Status
  • ##[group]
  • [command]

Remaining

• Customizable keymappings
• Customizable icons
• Update readme
• Cleanup code
• Customizable refresh interval
• Look into using graphql in favor of gh cli commands (not sure if strictly necessary but conforms to the repo standard)
• Use telescope pickers from the repo
• Understand the writers.lua file and extend it
• Use existing octo window creator

[wd60622]

Using graphql is not a big deal. Just use whatever endpoint that works. Think there are a few non graphql commands used.

[GustavEikaas]

Ah okay, functionality wise, do you have any feedback?

[wd60622]

Ah okay, functionality wise, do you have any feedback?

I will give it a try when I can!

[wd60622]

Think it looks good. Would you want to make use of the pickers instead of the new, custom buffer? I have been using telescope recently. What do you use?

Some items:

• What do you expect the callback to be upon selection an item? We can work something in like Abitrary callbacks for pickers #642 in order to support more in the future.
• Would there be a preview or buffer to show each item? What would be populated there? Maybe a buffer doesn't make sense here. What are your thoughts?

[GustavEikaas]

@wd60622 Is this what you meant, kinda like the PR and issue flow?

[GustavEikaas]

You still want there to be a buffer when you press <CR> on one of the items in the picker. AKA same flow as pull request?

[pwntester]

Thanks for the PR @GustavEikaas!

I like the idea of showing the status of the run in the preview buffer and perhaps show the logs of the run upon opening the item with <CR>. The problem I see is that a run may contain multiple jobs and each job will have its own log. Should we present them sequentially? thoughts?

[GustavEikaas]

IIRC the sequential jobs is already supported but yes I was thinking the same.
For the logs of every step we should probably lazy load and use fold or something similiar. Some steps have very long log outputs

[GustavEikaas]

@pwntester
Here is an image of what it looks like with multiple jobs

[GustavEikaas]

Doesnt seem like there is a good structured output for workflow logs. Will probably be tricky to have the same UI as github web.
Only way I see right now is query the workflow logs and using regex to match the lines to the corresponding steps

[pwntester]

Nice, perhaps we can do a nested telescope selection where the use first chooses the run and then the job, that should get us a shorter log to show to the user and it should easier to print since we dont need to care about job's dependencies, just sequential steps

[GustavEikaas]

I have been super busy at work so I have not had that much time to look at this but I finally got some time and this is how far I have gotten.

Features

• Telescope picker
• Telescope preview buffer
• Buffer
• > indicates a collapsable line
• Multi-job support
• Fetch logs on demand
• Yellow highlight means its a command (the line includes a [command]
• > inside the log text(purple highlight) means its a group (line include ##[group] and ##[endgroup]
• Expanding a step fetches the logs for the workflow and assigns corresponding log entries to all jobs and steps

Considerations

• It's pretty static at the moment and the cache is either 100% static, assign once and read forever. Or no cache, fetch every time invoked. There are a lot of ifs and buts for making a good cache control
• Interactivity. It would be nice for pending jobs to auto-refresh
• Mapping the correct line from the logs to the corresponing job & step is hard and fragile because the data is not structured
• Ansi codes were stripped, but ansi escape codes could probably be parsed in the future. Giving the users the colors they deserve
• Duplicate step names within the same job is indistinguishable from eachother making it impossible to map the correct log outputs

Stdout vs zip library

When mapping stdout to jobs/steps it uses string.find etc. This is error prone but pretty fast and easy way to do it.
It has some issues as mentioned in considerations section. The other option is to request the zip archive from githubs api which will return structured data, making it trivial to get 100% accurate workflow logs. e.x https://api.github.com/repos/<org>/<repo>/actions/runs/<run_id>/attempts/<attemp_number>/logs. The downside with this approach is both performance and prerequisites. It requires either a lua lib or terminal tool like unzip to handle the zip archive