ci: replace aws-micro runner with ubuntu-latest in all workflows

[Fedr]

Summary

Switch all 11 jobs that currently run on the self-hosted aws-micro runner to the GitHub-hosted ubuntu-latest runner.

MeshLib is a public repository, so all GitHub-hosted runners are free with no minute quota. ubuntu-latest on a public repo is 4 vCPU / 16 GB RAM, has no 15-minute per-job cap, and is the most plentiful runner pool — a strict resource and reliability upgrade over ubuntu-slim at the same (zero) cost.

Files changed

File	Jobs
.github/workflows/build-test-distribute.yml	3
.github/workflows/config.yml	1
.github/workflows/distro-release.yml	2
.github/workflows/prepare-images.yml	1
.github/workflows/unity-nuget-test.yml	2
.github/workflows/update-win-version.yml	1
.github/workflows/versioning-release.yml	1
Total	11 jobs

Why

• Removes dependency on a self-hosted aws-micro runner for lightweight orchestration work that doesn't need any custom environment.
• Cuts infrastructure: one fewer runner pool to maintain, provision, and keep alive.
• Free on this public repo.
• 4 vCPU / 16 GB RAM ubuntu-latest outperforms 1 vCPU / 5 GB ubuntu-slim on every job here, and avoids the 15-minute ubuntu-slim job cap.

Why not ubuntu-slim?

An earlier iteration of this PR used ubuntu-slim. It works, but ubuntu-slim only pays off on private repos where the 3× cheaper per-minute rate stretches the included-minute pool. On this public repo there's no minute pool to stretch — ubuntu-latest is the same price (free) with strictly more resources.

Bug fixed along the way (commit 38173a4)

The first CI run on this branch exposed a latent bug in build-test-distribute.yml: the collect-stats job's Install dependencies step pip-installed only boto3 botocore, but scripts/devops/collect_ci_stats.py also imports requests. On the old aws-micro runner requests was preinstalled in the system Python, so this went unnoticed. On a clean GitHub-hosted runner image it fails with ModuleNotFoundError: No module named 'requests'. Fixed by adding requests to the pip install line.

Submodule cleanup (commit fda697e)

The config.yml :: prepare-config job was the only aws-micro-side job using submodules: true on its checkout. It runs only uv / pre-commit, dorny/paths-filter, and a few branch-name shell snippets — none of which touch submodule contents — so the submodule pull was pure waste.

This turned out to be the single biggest performance win in the PR. Step-level breakdown of config / prepare-config:

Configuration	Checkout	Checkout full history	Total job run
aws-micro · with submodules	3 s	4 s	18 s
ubuntu-slim · with submodules	46 s	12 s	74 s
ubuntu-slim · without submodules	3 s	11 s	27 s
ubuntu-latest · without submodules	3 s	8 s	22 s

Removing submodules cut the whole job from 74 s → 27 s on ubuntu-slim — a 64% reduction. Submodule pull was 46 s on a clean GitHub-hosted runner with no git object cache (vs. 3 s on the warm self-hosted aws-micro box), so it was the dominant cost.

(All other previously-aws-micro jobs either don't check out the repo at all, or already checkout without submodules.)

CI timing comparison: 3-way

aws-micro (master run 24898903382) vs. ubuntu-slim with submodules (PR run 24897744204) vs. ubuntu-latest without submodules (PR run 24913987716):

Job	aws-micro wait/run	ubuntu-slim wait/run	ubuntu-latest wait/run
config / prepare-config	1 s / 18 s	4 s / 74 s	3 s / 22 s
debug-config	1 s / 3 s	3 s / 4 s	2 s / 2 s
prepare-image / always-success	5 s / 2 s	4 s / 5 s	2 s / 4 s
versioning-and-release-url	8 s / 58 s	3 s / 67 s	3 s / 58 s
collect-stats	2 s / 18 s	5 s / 45 s	3 s / 27 s
update-artifacts	2 s / 21 s	5 s / 49 s	2 s / 45 s
Totals (sum)	19 s / 120 s	24 s / 244 s	15 s / 158 s

What the timings show

• Wait time is a non-issue. ubuntu-latest's 15 s aggregate is better than aws-micro's 19 s — the ubuntu-latest pool is plentiful enough that scheduling never bites.
• ubuntu-latest recovered ~70% of the runtime regression that ubuntu-slim introduced. Run-time delta vs. aws-micro: +38 s total (vs. +124 s on ubuntu-slim).
• Critical-path impact of switching: only config / prepare-config (+4 s) at the start and update-artifacts (+24 s) at the end of the pipeline are on the critical path. Net wall-clock added: ≈ +28 s — small relative to a multi-hour build matrix.
• update-artifacts is the largest remaining gap. Looking at its steps, it's I/O bound (artifact download/upload over GitHub-hosted-runner network), not CPU-bound, so a bigger runner wouldn't help further.

Test plan

• Every affected workflow still starts its ubuntu-latest-hosted job successfully
• No self-hosted-only tool / filesystem dependency surfaces in these jobs (one that did — implicit requests — is now declared explicitly)
• Per-job timing on ubuntu-latest is at most slightly slower than aws-micro (i.e. no critical-path regression beyond +28 s)

🤖 Generated with Claude Code