Gitea Runner: Official Gitea Actions runner for CI/CD processes.

The release of Gitea Runner 1.0.0 represents more than just a version bump; it signifies a structural refinement of the CI/CD pipeline within the Gitea platform. For developers integrating automated workflows, this transition is key because it formalizes the tool and improves its technical cohesion. By explicitly renaming the tool and establishing new, consistent naming standards across the repository, binary, and container image, the maintainers have removed historical ambiguities associated with previous implementations like `act_runner`. From a developer experience standpoint, the primary benefit is predictability. The explicit guidance provided for the new invocation steps—such as using `./gitea-runner register` and `./gitea-runner daemon`—simplifies deployment scripts and service definition files. Furthermore, the strong push toward generating and utilizing a dedicated `config.yaml` file is a significant architectural improvement. While environment variable setup remains functional, relying on an explicit configuration file makes the runner's operational parameters—like cache settings, labels, and resource allocation—manageable and auditable, which is crucial for complex, enterprise-grade CI/CD setups. Teams upgrading existing installations should pay close attention to the migration path. The transition requires updating various deployment artifacts, including Docker Compose files, Kubernetes manifests, and internal service scripts, to reference the new `gitea-runner` binary and `gitea/runner` image. This intentional reset (v1.0.0) ensures that all consumers are starting from a documented, stable baseline, making the migration largely a straight rename effort for most deployments. However, users relying on custom Docker-in-Docker or rootless Docker setups must thoroughly test their workflows against the new version to ensure label resolution and resource isolation remain intact. Overall, Gitea Runner 1.0.0 delivers a more professional, maintainable, and technically defined CI/CD component. It moves the tool from a historically derived package into a genuinely core, platform-native service. This level of technical refinement reduces vendor lock-in concerns within the Gitea ecosystem and provides developers with a clearer, more stable toolchain for modern deployment practices.