DEV Community: Matej Lednický

GitHub Runner Cleanup: A Reusable Action 🚀🧹💾

Matej Lednický — Fri, 11 Jul 2025 16:06:39 +0000

Some time ago, I wrote a DEV.to article about reclaiming disk space in GitHub Actions:

Squeezing Disk Space from GitHub Actions Runners: An Engineer's Guide 🚀🧹💾

tl;dr GitHub Action runners come preloaded with a lot of useful software that—well—might not be useful for your use case at all.

Reusable GitHub Action ⚙️

I’ve published a reusable GitHub Action to help you clean up unnecessary tools, packages, and caches—and free up valuable disk space during your CI runs.

➡️ Check it out on GitHub Marketplace:

https://github.com/marketplace/actions/runner-cleanup-action

➡️ Use it in your GHA workflow:

- uses: mathio/gha-cleanup@v1
  with:
    remove-browsers: true # or false if you need to run tests or automation in browser
    verbose: true # or false if you do not care about logs

For full documentation and source code, visit my GitHub repository:

👉 mathio/gha-cleanup

Lingo.dev Compiler is here 💚

Matej Lednický — Tue, 03 Jun 2025 20:24:29 +0000

Max Prilutskiy

Jun 3 '25

Introducing Lingo.dev Compiler: Localize a React app without rewriting its code

#react #webdev #javascript

Comments 15

3 min read

Squeezing Disk Space from GitHub Actions Runners: An Engineer's Guide 🚀🧹💾

Matej Lednický — Tue, 27 May 2025 19:05:54 +0000

Last week I was deploying our Lingo.dev app as a Docker image from a GitHub Action. And to deploy it, I had to build it inside on a Github-hosted runner. However I hit the limit:

"You are running out of disk space."

Have you ever hit this sudden and mysterious failure in your GitHub Actions workflow too?

As our CI pipelines grew in complexity and size, we run out of disk space on GitHub-hosted runners. In this practical guide, I’ll show you what fills up the disk, how I analyzed it, and what I did to reclaim enough space to make my builds reliable again.

💡 tl;dr go to chapter 6 and copy the Github Action step to clean up your Github-hosted runner.

1. The Limits of GitHub-hosted Runners

GitHub-hosted runners come preloaded with a wide variety of programming languages, SDKs, and tools. This is great for convenience, but the trade-off is bloat. Here's what a typical ubuntu-latest runner includes:

Preinstalled languages: Java (multiple JDKs), .NET, Python, Ruby, Go, Swift, Haskell (GHC), Julia, Node.js
Developer tools: Android SDK, Docker, Azure CLI, Google Cloud SDK, CodeQL, browsers (Chrome, Edge, Firefox), Chromium
Miscellaneous: PowerShell, Rust toolchains, LLVM, debugging tools

Out of ~72 GB total disk, over 50 GB is used before any workflow step runs.

2. Hitting the Wall: My Symptoms

I was building and deploying Docker images using a GitHub Actions workflow. Everything worked fine until the job suddenly failed with a disk space error during the Docker build phase.

You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 54 MB

This prompted me to figure out what was actually eating up all the space.

3. Measuring the Beast: How Much is Used and Where 🤔

To understand the problem, I added the following steps to the GitHub Actions workflow:

- name: Show disk usage
  run: df -h

- name: Top-level directories
  run: du -h -d1 / | sort -hr | head -n 20

- name: Detailed file sizes
  run: find / -type f -exec du -h {} + 2>/dev/null | sort -hr | head -n 1000

Here's what I found:

/usr: 34 GB — this directory holds most system software and preinstalled runtimes like Java, Swift, and .NET. It's often the largest.
/opt: 11 GB — contains hosted toolcaches for things like CodeQL, Go, and language-specific tools that GitHub Actions preinstalls.
/mnt: 4.1 GB — usually used for temporary mounts or ephemeral files. Sometimes includes scratch space used during builds.
/home: 1.2 GB — stores user-level data, including runner-specific config, caches, and things like rustup toolchains.

Looking closer, it was clear that /usr/share/swift, /usr/local/.ghcup, and /usr/local/lib/android were some of the biggest space hogs.

4. What's Hiding in Your Runners?

Most of the disk was taken up by things I didn’t need. Here's a breakdown:

Languages and Runtimes

Tool	Path	Approx Size
Java	`/usr/lib/jvm`	~1.5 GB
.NET	`/usr/share/dotnet`	~1.5 GB
Swift	`/usr/share/swift`	~2.5 GB
Haskell	`/usr/local/.ghcup`	~3 GB
Rust	`/home/runner/.rustup`	~1.5 GB
Julia	`/usr/local/julia*`	~500 MB
Android SDK	`/usr/local/lib/android/sdk`	~6 GB
Browsers	`/usr/local/share/chromium`, etc.	~1.5 GB

Developer Tools

Tool	Path	Approx Size
CodeQL	`/opt/hostedtoolcache/CodeQL`	~2 GB
PowerShell	`/usr/local/share/powershell`	~800 MB
Azure CLI	`/opt/az`	~200 MB
Google SDK	`/usr/lib/google-cloud-sdk`	~200 MB

5. What Can You Safely Remove? 🗑️

Depending on your use case, you can remove different tools. Since I was building and deploying Docker images for a Node.js application, I didn’t need most preinstalled SDKs and languages.

Here are a few examples:

Node.js project: remove Java, .NET, Swift, Haskell, Android SDK, CodeQL
Python scripts: remove Java, .NET, Android, Browsers
Java application: remove Swift, Haskell, CodeQL, Node.js, Android SDK

In general, you can also remove browsers like Chromium if you’re not using them for end-to-end testing.

6. How to Automate Cleanup in Your CI 🚮

I added this step to the top of my GitHub Actions workflow:

- name: Aggressive cleanup
  run: |
    # Remove Java (JDKs)
    sudo rm -rf /usr/lib/jvm

    # Remove .NET SDKs
    sudo rm -rf /usr/share/dotnet

    # Remove Swift toolchain
    sudo rm -rf /usr/share/swift

    # Remove Haskell (GHC)
    sudo rm -rf /usr/local/.ghcup

    # Remove Julia
    sudo rm -rf /usr/local/julia*

    # Remove Android SDKs
    sudo rm -rf /usr/local/lib/android

    # Remove Chromium (optional if not using for browser tests)
    sudo rm -rf /usr/local/share/chromium

    # Remove Microsoft/Edge and Google Chrome builds
    sudo rm -rf /opt/microsoft /opt/google

    # Remove Azure CLI
    sudo rm -rf /opt/az

    # Remove PowerShell
    sudo rm -rf /usr/local/share/powershell

    # Remove CodeQL and other toolcaches
    sudo rm -rf /opt/hostedtoolcache

    docker system prune -af || true
    docker builder prune -af || true
    df -h

This alone saved more than 20 GB of space.

7. Bonus: Logging & Debugging Disk Usage Over Time 📊

To keep an eye on disk usage trends or debug failures, I uploaded disk logs as artifacts:

- name: Upload disk logs
  uses: actions/upload-artifact@v3
  with:
    name: disk-logs
    path: logs/

I generate the logs using tools like df, du, and find, and use them for future audits.

8. Final thoughts

Disk space can quietly break your CI/CD pipelines. GitHub-hosted runners are filled with helpful tools, but many are unnecessary for your project. By auditing and removing what's not needed, I was able to consistently reclaim 15–25 GB of space and run Docker builds reliably.

Feel free to use the Aggressive cleanup step (see above) in your own Github Action.

If you're running into disk issues, don’t jump to larger runners. Start by cleaning up what you don’t use.

Let me know on X @mathio28 if you had a similar issue.

Images:

Photo by Bruce Hong on Unsplash
Photo by Roman Synkevych on Unsplash

To infinity and beyond 🚀

Matej Lednický — Wed, 19 Feb 2025 16:06:17 +0000

We just raised $4.2 to keep building our hackathon project!

Max Prilutskiy ・ Feb 19

#webdev #javascript #hackathon

Building Cross-Platform CI/CD Actions with Docker

Matej Lednický — Wed, 29 Jan 2025 15:51:09 +0000

Last week I got hit by a headache - our perfectly tuned Lingo.dev GitHub Actions workflow couldn't run on a contributor's GitLab instance. Then I realized I’d actually like to run the same automation everywhere, regardless of the platform.

So I went on a quest to build a cross-platform CI automation that runs on GitHub, GitLab, and Bitbucket (and possibly others too!). The solution started as a simple GitHub Action but evolved into something more powerful when we needed to support multiple code hosting platforms.

I will walk you through the exact process:

starting simple, I will showcase how Github Actions work
leveling up to build reusable Docker image
finally I will show you how to run this on each platform

Follow the steps to build and ship your first cross-platform action. Or bookmark the article for later.

tl;dr see the template repository 👇👇👇

1. Starting Simple: Run JavaScript in GitHub Actions

Running a GitHub Action

Let's start with the simplest possible GitHub Action - one that runs a JavaScript file. First, create index.js in the root of your repository:

console.log("Hello World");

Now create a workflow file .github/workflows/hello.yml:

name: Hello World
on:
  push:
    branches:
      - main

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Say Hello
        run: node index.js

This action will:

Trigger on push to main branch
Check out your repository
Set up Node.js environment
Run your script

Making it Reusable

Now, let's make this action reusable by moving it to a separate repository. Create a new GitHub repository (e.g., hello-world-action like my example here) with these files:

index.js (same as before):

console.log("Hello World");

action.yml:

name: "Hello World Action"
description: "A simple action that says hello"
runs:
  using: "node20"
  main: "index.js"

Now you can use this action in any repository by referencing it in your workflow:

name: Use Hello Action
on:
  push:
    branches:
      - main

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        uses: your-username/hello-world-action@main

The key differences are:

The action lives in its own repository
action.yml defines how to run the action
Other repositories can reference it using uses: your-username/hello-world-action@ref

2. Leveling Up: Dockerized TypeScript Action

Now, let's create a more sophisticated action that runs TypeScript code. We'll need several files:

Initialize the project and set up TypeScript:

pnpm init                # Creates package.json
pnpm add -D typescript   # Install TypeScript as dev dependency

Update your package.json to add the build script:

{
  "scripts": {
    "build": "tsc"
  }
}

Then rename our index.js to index.ts to use TypeScript instead of JavaScript and move it to the src directory.

Create tsconfig.json to configure TypeScript compilation:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "commonjs",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "exclude": ["node_modules", "build", "**/*.test.ts"]
}

Create a Dockerfile:

FROM node:20-slim

WORKDIR /app

# Install pnpm
RUN npm install -g pnpm

# Copy package files
COPY package.json pnpm-lock.yaml tsconfig.json /app

# Copy source code
COPY src /app/src

# Install dependencies
RUN pnpm install

# Build TypeScript code
RUN pnpm build

# Run the action
ENTRYPOINT ["node", "./build/index.js"]

Redefine the action in action.yml:

name: "Hello World TypeScript Action"
description: "A cross-platform TypeScript action example"
runs:
  using: "docker"
  image: "Dockerfile"

Running Docker Image Locally

To build and run the image defined in Dockerfile locally, you need Docker Desktop app. Then, assuming Docker is running locally, you can:

Build the image:

docker build -t hello-world-action .

Run it:

docker run hello-world-action

3. Cross-Platform Support

Now comes the most interesting part - running your action on other platforms. We'll need to:

Build and push our Docker image to a registry
Reference it in platform-specific configurations

Building and Publishing Docker Image

First, create a workflow to build and push the Docker image on every release. We will be using GitHub Container Registry (GHCR) that comes with your GitHub (free for public repositories, 500MB for private repositories on free plan).

name: Publish Docker image
on:
  push:
    branches:
      - main

jobs:
  push_to_registry:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

Github Actions

To use this action in GitHub Actions of another repository, create a workflow file in .github/workflows/hello.yml (see GitHub Actions workflow syntax documentation):

name: Run Hello World
on:
  push:
    branches:
      - master

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - uses: your-username/hello-world-action@main

If you need to run this action on GitHub Actions only, there is no need to build and push the Docker image. GitHub Actions will build the Docker container directly from the Dockerfile specified in your action.yml file on each workflow run. This is more efficient since it avoids the extra steps of pushing to and pulling from a container registry. However, if you plan to use this action on other CI platforms like GitLab or Bitbucket, you'll need to publish the Docker image as shown above.

GitHub's free plan offers the most generous CI/CD minutes allocation among the three platforms. It includes:

unlimited minutes for public repositories
2,000 minutes/month for private repositories

GitLab CI Configuration

Create .gitlab-ci.yml (see GitLab CI/CD documentation):

hello:
  image: ghcr.io/your-username/hello-world-action:latest
  script:
    - echo "Done"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"

Your Gitlab free plan includes 400 CI/CD compute minutes per month regardless if the repository is public or private.

Bitbucket Pipelines

Create bitbucket-pipelines.yml (see Bitbucket Pipelines documentation):

image: docker:latest

pipelines:
  branches:
    main:
      - step:
          image: ghcr.io/your-username/hello-world-action:latest
          script:
            - echo "Done"

Bitbucket's free plan includes only 50 build minutes per month, regardless if the repository is public or private, making it the lowest free tier of all three platforms.

Other CI/CD Platforms

Since we published our Docker image in a public Github Container Registry, we can run this on any platform that supports Docker images. This is supported by:

Circle CI (docs)
Travis CI (docs)

Let me know if you run this somewhere else, I am curious about your use case!

💡 What can you do with this?

We built an action to run automated Lingo.dev localization for your web and mobile apps on any CI platform. On every commit it updates translations in your entire repository using Lingo.dev localization engine - either as a new commit or by opening a pull request (docs).

Example for GitHub:

- uses: lingodotdev/lingo.dev@main
  with:
    api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
    values:
        pull-request: 'true' # or false, we don't judge

You can build reusable actions and easily integrate them into your workflows regardless of the code hosting platform you are using. Here are some ideas for you:

cross-platform test reporter (orchestrating end-to-end testing session)
custom code quality checker (think formatting, linting, testing)
release notes generator (how about publishing a changelog on your website?)

What would you use it for?

💥 Bonus: Template repository

If you don't feel like reading the rest of the article, you can find a template starter repository with all the code here. It contains the action - you can run it on GitHub, GitLab and Bitbucket.

https://github.com/mathio/awesome-action-starter

💡 Tip: Clone the repo and make it a starting point for your own action:
git clone https://github.com/mathio/awesome-action-starter.git my-action
cd my-action
…or just create a new repository from my template.

Then just implement your own action logic in src/index.ts file.

Conclusion

We've seen how to evolve from a simple shell-based GitHub Action to a sophisticated TypeScript action that can run anywhere. The key takeaways are:

Start simple with shell commands to validate your automation logic
Dockerize your action to make it portable
Use container registries to distribute your action across platforms
Adapt the configuration for each platform while keeping the core logic in Docker

This approach gives you the flexibility to run your automation anywhere while maintaining a single codebase. Happy automating!

I occasionally post about tech stuff and new Lingo.dev features on Twitter as @mathio28. Let's keep in touch.