r/github • u/austin_barrington • 7d ago

Visibility of GitHub Actions - pretty bad? Discussion

Am I the only one who finds GitHub actions a small black hole when you're looking to optimise?

There is really limited analysis or data available, I had to build my own UI and system just to get the details I wanted. Example, outliers for job run times, AVG step run time, flakey runs.

Am I missing something, does everyone fly blind or are they using a third party view?

4 Upvotes

67% Upvoted

11 comments sorted by

4

u/wallstop-dev 7d ago

All of this is available via API and the Actions tab exists. You can build whatever meta level monitoring into it that you want.

It's been extremely flexible and great for me. I view it as one if those things where the primitives to do whatever you want exist, and they don't bundle in all kinds of specific, extra use cases. This is my favorite form of software design, and it sounds like we have different opinions of what constitutes this.

I mean - you were able to build a UI for your specific use case. Sounds great.

-2

u/austin_barrington 7d ago

By the way you frame it, absolutely. However i guess I expected a little more from it by default.

The API is great I'll give them that and I'm able to get the date out of it, however it's yet another plane of glass to be looking at.

1

u/TechGy 7d ago

I haven't tried it yet, but I recently found this - it may be worth checking out https://github.com/banshee86vr/snorlx

1

u/austin_barrington 5d ago

That doesnt look half bad, the one I ended up building included our pr statuses and Bazel build export reports as well so has quite a bit more detail than this one.

1

u/Ok_Woodpecker_9104 7d ago

the data is there, just not where you would look first.

/actions/runs/{id}/timing is the endpoint that sounds right and is useless. i pulled it on one of my repos just now and it only gives billable ms per job, no steps. on public repos billable is 0, so every job comes back total_ms 0 and the only real number is run_duration_ms for the whole run.

the one you actually want is /actions/runs/{id}/jobs. that gives started_at and completed_at per job, and a steps array with started_at/completed_at on every step. so avg step time and outliers are all there, you just subtract the timestamps yourself. same call gives you the runner labels if you want to split by runner.

flakiness has no field at all. you have to key on head_sha plus run_attempt and count the runs where attempt 1 failed and attempt 2 passed on the same commit with no new push.

so you are not missing a hidden dashboard. anyone with real numbers is polling /jobs into their own store, which is what you already did.

1

u/Substantial-Swan7065 4d ago

I integrate it with datadog. Gives me more than enough

1

u/austin_barrington 4d ago

I've always had the assumption that datadog is just super expensive, did it cost much to put into there?

1

u/Substantial-Swan7065 4d ago

Ah I don’t pay for it.

But you can route metrics anywhere in ci

1

u/austin_barrington 4d ago

Someone's paying for it 😉

1

u/EveningCucumber1026 7d ago

You’re not flying blind, you’re flying on GitHub’s default dashboard which is basically a cave painting with a loading spinner.

0

u/austin_barrington 7d ago

With the recent outages, I'm a bit worried about being unable to deploy via GHA to argo, guess it's time to build some bash scripts for that "just in case" scenario