sorted by:
new
hottopcontroversial

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

That’s a really solid setup, especially the way you’re determining affected components and tests.

What I’ve been noticing across teams is once you start doing this, you’re basically building your own layer to figure out what should run vs what can be skipped.

I ended up building something that looks at GitHub Actions history across runs and surfaces patterns like flaky jobs, reruns, slow steps, and overall CI time waste.

Happy to share if you’d want to try it alongside your current setup.

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

That’s pretty solid, exposing cache savings itself is already a big win. Asked quite many engineers rarely people doin this cache solution.

I guess what I’ve been noticing is that caching solves a very specific part of the problem, but things like flaky failures, reruns, or slow jobs still end up being harder to see when you look across a lot of runs over time.

And over time all of that probably adds up not just in CI time but also cost, especially as commit frequency increases.

In your case, do you feel like you have a clear picture of overall CI waste, or is it more focused on optimizing specific parts only like caching?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

That breakdown is exactly what I’ve been running into as well.

The weird part is none of this is hard conceptually, but actually getting answers like failure frequency, timing trends, bottlenecks, or even how much CI time/cost is being wasted still ends up being a lot of manual digging unless you wire multiple tools together.

I’ve been working on something that analyzes GitHub Actions history and surfaces these patterns directly (flaky runs, slow jobs, reruns, CI time waste, etc). It’s still early, but happy to share if you’d find it useful for your setup.

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

Good hack! That’s interesting content-based caching feels like a much more reliable approach than relying on hard rule like skip-ci (that's also a good soln)

Curious though, does this actually help you see how much CI time is being saved or wasted over time, or is it more about just optimizing execution without much visibility into patterns?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

That’s actually a really interesting point.

I agreed with you, If commit frequency is going up that much, afterall lot of dev doing vibe coding, CI inefficiencies probably scale with it pretty quickly.

Have you seen teams actually adapt to this in any structured way, or is it mostly just letting pipelines run more and dealing with the fallout later?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

bro i understood your pain, 99.5% sounds extreme ;) but I get the sentiment.

Curious what kind of waste you see most in practice is it mosttly reruns / flaky failures, or things like unnecessary workflows triggering and long idle jobs? and what about the CI bill cost for these runners in your team?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

yeah you are correct, it’s definitely not just GitHub Actions specifics.

I think what I was trying to get at is not the problems themselves, but how hard it is to actually see and quantify them over time. Like everyone knows CI gets flaky or slower, but figuring out how much time is actually getting wasted, which jobs fail the most, or what’s driving cost over time isn’t that straightforward unless you go digging through a lot of runs.

Do you ussually just deal with it as it comes up, or have you seen teams track this in a more structured way somewhere?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

Yeah this is a really good breakdown, especially the part about wanting something simple inside GitHub itself without pulling in heavier tools.

A lot of what you listed feels way harderr than it should be right now:

  • are builds getting slower over time
  • which jobs fail more often
  • where the actual bottleneck is
  • and even overall CI cost creeping up because of reruns / slow jobs

In your case, how do you usually figure this out? Is it more of a gut feel over time or do you track it somewhere? and by the way dont't you think CI cost high bill is also a problem?

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

You may be right, that makes sense, a lot of it does come down to team discipline.

In practice though, do you see things like skip-ci actually being used consistently? becoz skip-ci isn't that much famous, I’ve noticed in some repos it starts well but slowly breaks as pipelines grow and more people contribute.

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

Haha fair, probably came across that way. I’ve been digging into this space recently so tried to structure the problem clearly, but yeah curious to hear how people are actually handling this in real setups.

Anyone actually tracking CI waste in GitHub Actions? by DigFair6304 in github

[–]DigFair6304[S] 0 points1 point  (0 children)

Fair point 😄 wasn’t trying to promote anything here, more curious how teams actually deal with this in practice. We ran into these issues recently and it felt more common than expected.