CI/CD Runner Infrastructure¶

Infinite Loopers used Gitea Actions to automate quality checks, testing and deployment workflows across Toodle's frontend, backend and documentation repositories. Shared-runner delays led the team to establish dedicated infrastructure so automated feedback could support development more reliably.

This page records the team's runner journey. Hosting details and observed timings come from that development account; the configuration notes below distinguish them from what the available repository files verify.

Shared Runners and Local Docker¶

The project initially relied on two shared Gitea runners serving multiple teams. Near deadlines, queues sometimes exceeded 10–15 minutes, jobs remained at Set up job, and the team had limited visibility into failures or control over restarting the infrastructure.

The first alternative was Docker Desktop on a team member's computer, with three runner containers: one each for the frontend, backend and documentation repositories. This reduced waiting and gave the team access to runner logs and configuration. However, availability depended on the computer remaining powered on and connected to the internet, making it unsuitable as the main long-term solution.

Comparing Cloud Options¶

Option	Experience and decision
Oracle Cloud Always Free	An Ubuntu VM was provisioned, but its 1 GB RAM struggled with Docker workloads. An Out of host capacity error later prevented the instance from restarting. The team could not rely on its availability.
Google Cloud	Activating the available trial required an upfront payment in the team's experience. The team chose to continue looking for an option without personal expenditure.
Azure for Students	The student offering allowed provisioning without an upfront credit-card payment. The team selected Ubuntu Server 22.04 with 2 vCPUs and 4 GB RAM, running Docker, Docker Compose and three dedicated Gitea Actions runners.

Moving the runners to Azure removed the dependency on a personal computer remaining online. These comparisons describe the team's experience at the time, rather than general claims about providers' current pricing or availability.

Technical Challenges and Reliability Improvements¶

Predictable Job Assignment¶

Initially, the dedicated runners used the same ubuntu-latest label as the shared infrastructure, so jobs could still be assigned to global runners. The team introduced toodle-runner to direct workflows to its dedicated infrastructure. A workflow label must match a registered runner label; using an unmatched label leaves jobs waiting.

Docker Networking and Caching¶

Network failures and long npm-cache restore/save delays required investigation of communication between runner containers, job containers and Docker networks. The team adjusted networking and disabled problematic cache settings.

The backend workflow provides concrete evidence of one networking decision: its integrity-test job expects host networking. Instead of relying on a service container reachable as postgres, it installs and starts disposable PostgreSQL inside the job container and connects through loopback. This supports real database tests without accessing the application database.

Connection Stability and Recovery¶

Some runners appeared offline in Gitea while their Docker containers were still running. The team's investigation pointed to idle network connections being closed, and Linux TCP keepalive settings were adjusted. Jobs that Gitea continued to display as running after execution had stopped were manually cancelled and rerun.

These adjustments highlight the difference between a running container, a connected runner and a progressing job. The available repositories do not contain the VM's keepalive settings or the runner Compose configuration, so their exact deployed values were not independently checked.

Recorded Final Architecture¶

The team's final account describes one Azure for Students VM hosting three dedicated runners:

flowchart TB
    G[Gitea Actions — Infinite Loopers repositories]
    subgraph VM[Azure for Students VM — Ubuntu Server 22.04]
        D[Docker Engine and Docker Compose]
        F[Frontend runner]
        B[Backend runner]
        R[Documentation runner]
        D --> F
        D --> B
        D --> R
    end
    G -->|toodle-runner label| F
    G -->|toodle-runner label| B
    G -->|toodle-runner label| R

Each repository retains its own checks and deployment configuration. This is runner infrastructure for executing automation, separate from the platforms hosting the application and documentation.

Repository Verification¶

Repository revision inspected	Runner targeting verified
Frontend `origin/develop`, `.gitea/workflows/ci.yml`	The lint, test and build job uses `toodle-runner`.
Backend `origin/develop`, `.gitea/workflows/ci-cd.yaml`	Quality checks, PostgreSQL integrity tests and the deployment job use `toodle-runner`.
Documentation `origin/main`, `.gitea/workflows/docs.yml`	The documentation build/deployment job uses `toodle-runner`.

The local documentation checkout currently retains ubuntu-latest, so it differs from fetched origin/main. No workflow was changed for this documentation update. Workflow files verify the intended label selection; they do not independently establish the Azure VM's current availability, runner registration or successful hosted runs.

Results and Lessons Learned¶

The team reported waiting/execution periods of 10–15+ minutes with shared runners during delays, compared with approximately two minutes for typical lint/test pipelines on dedicated runners. These are development observations, not a controlled benchmark separating queue time from execution time.

Dedicated infrastructure gave the team control over configuration, access to container logs and independence from shared runner capacity. Maintaining that control also meant taking responsibility for networking, resources, connection stability and recovery.

The main lessons were to match workflow and runner labels, investigate failures across both runner and job containers, and verify job progress rather than treating a running container as proof of health. Keeping a local Docker configuration offers a fallback when cloud runners are unavailable.

This work supported an adapted Scrum methodology by reducing delays between implementation, testing and review. Branching and review practices remain in Git & Quality Process; application hosting is covered in Deployment and Hosting.