When GitHub Actions Decides to Take a Break

I have a few personal projects where I just commit some code now and then.
At the moment, I’m using GitHub Actions as both my repository and my build server.

Although GitHub Actions isn’t necessarily bad compared to its competitors, I still had to wait at least 5 minutes for each build.
And my pipeline does almost close to nothing — let’s say it runs 10 tests.

But suddenly, GitHub decided to slow down to 20 minutes per build.

Why? Good that you ask.

---

The Investigation

I invested some time to search for my bottleneck.

• What’s the last thing I committed?
• How could that cause such a slowdown?
• It’s just a unit test.
  No integration tests, no regression, nothing heavy.
  Just a unit test? But why did it slow down?

Let’s try to run it locally.

❯ time ./gradlew test

.....................

BUILD SUCCESSFUL in 6s
6 actionable tasks: 4 executed, 2 up-to-date

real    0m6.400s
user    0m1.328s
sys     0m0.106s

Well, I doubt that’s the problem.

Let’s dig a bit deeper. Let’s look at the action itself — what actually takes that long?

Fascinating? Somehow the build times completely changed.
The Gradle build first took ~2 minutes, and now it’s close to ~7 minutes.
What?! Even the POST build step moved up a notch.

Looking at the actions revealed the issue:

build
Failed to save cache entry with path '/home/runner/.gradle/caches,/home/runner/.gradle/notifications,/home/runner/.gradle/.setup-gradle' and key: gradle-home-v1|Linux|build[ec2f5341d16bc4782e65bfe2ffbba5ff]-2efb491ecb9215574dfc9890f706afb9697f17f3: 
Error: reserveCache failed: connect ETIMEDOUT 52.152.245.137:443

Ah, I get it now — apparently, we have a Gradle caching issue, no idea why. But hey, like most things in software development, lets update.

---

The Update

I was using versioned actions, like this:

- name: Build with Gradle
  uses: gradle/gradle-build-action@v3
  with:
    arguments: build

Okay, my bad, apparently I was using a very old build action.
Thank you, AI 🙃

Let’s fix that and see what happens with the build:

steps:
  - uses: actions/checkout@v4

  - name: Set up JDK
    uses: actions/setup-java@v4
    with:
      java-version: '21'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@v4

  - name: Execute Gradle build
    run: ./gradlew build

This Looks better? — commit!

---

🎉 This Worked

Well, apperently that worked, my build is back to its normal speed — around 5 minutes.

---

This leaves me a bad taste

This is exactly what I hate about all the build systems.
Out of nowhere, they need help. A LOT

For some reason or another, we constantly have to babysit the build system:

• Fix caches
• Fix versioning
• YAML updates

This is all boilerplate, not to help me, but to help the CI.

---

Why We Built Zippy

At Zippy, we are done with these kind off problems.

That’s why we worked really hard to make a system that suits the developer, not the system.

With Zippy, I just push — and my build is done in 24 seconds with realtime feedback! BOOM.

I’m in complete control. No weird slowdowns, no configuration breaks, no YAML debugging at 2am.

---

Want a CI that works for you?
Check out Zippy — built by developers, for developers.