Gitea Releases Runner v4: Shared S3 Cache and Faster CI/CD with Built-in Actions

AIDeveloper44 Team

Overview of Gitea Runner 4.0.0

Gitea has announced the release of Gitea Runner 4.0.0, a significant update to its CI/CD runner technology. This version focuses on improving efficiency and simplifying infrastructure requirements for development teams. While the release features a major version bump, the project maintainers clarify that this reflects specific breaking changes in the runner's architecture rather than requiring a new server dependency. The software remains wire-compatible with existing Gitea versions currently in use.

Key Features and Improvements

A primary addition in this release is the support for built-in actions, specifically builtin:checkout. This functionality allows the runner to execute native Go actions directly. By using uses: builtin:checkout, developers can perform repository cloning without needing to download external action code or ensure Node.js is present in the job's container image, thereby speeding up pipeline setup times and reducing potential points of failure.

For teams managing large build environments, the introduction of a shared S3-compatible cache is a notable improvement. Previously, runners often required a separate cache server. Version 4.0.0 enables runners to interface directly with S3-compatible storage solutions—such as AWS S3, MinIO, or RustFS—to store and retrieve action caches. Runners sharing the same settings can access a common cache pool, with cached data becoming available to other runners in the cluster within approximately 30 seconds. This capability allows for more scalable and resilient ephemeral runner configurations.

Observability has also been enhanced through the integration of OpenTelemetry tracing. Operators can now configure runners to send job traces to an OTLP collector. Each step in a job generates a specific span, which can be configured using standard OTEL_* environment variables. This provides deeper insight into CI/CD pipeline performance and behavior.

Workflow and Configuration Changes

The update introduces a more flexible way to reference actions with the self: prefix. Developers can now use uses: self:{owner}/{repo}[/{path}]@{ref} to resolve actions within the same Gitea instance, removing the need to hard-code hostnames. Furthermore, the runner now supports --umask in container options, providing better control over file permissions for processes running within containers.

Important Breaking Changes

Users planning to upgrade should be aware of two specific breaking changes:

• Cache Request Routing: Job-level cache requests are now routed through the runner itself. Previously, jobs communicated directly with the cache server. This change means that external cache servers no longer need direct connectivity to the Gitea instance, but they must be accessible by the runner. If jobs cannot reach the runner, configuration adjustments involving cache.host and cache.port may be required.
• Volume Matching: The valid_volumes configuration now uses doublestar matching rather than the previous glob implementation. Patterns using * will no longer cross directory boundaries. Configurations that previously relied on * to match nested paths must be updated to use ** to maintain existing functionality.

The Gitea team recommends testing artifact uploads, cache restoration, and network configurations in a staging environment before performing a broad rollout to production infrastructure. The release is currently available for various platforms via the official Gitea Runner release pages.

Enjoyed this?

Get more posts like this delivered to your inbox.

Subscribe