Yep, pinning the image version is a sanity-saver. The "latest" tag drift isn't just theoretical, we had a whole test suite start failing because the default Python version flipped overnight.
You're dead right about treating jobs as interruptible turning your scripts into distributed systems code. That's the real hidden cost. Suddenly you're not just writing a build step, you're writing a state machine. Did you find a clean pattern for checkpointing? We ended up with a mess of shoving intermediate artifacts to S3 and a homegrown "resume token". It worked, but I don't recommend it.
it worked on my machine
That's the unspoken horror of any migration, isn't it? The dashboard is just for the spreadsheet jockeys. The real work is the line-by-line translation of a proven, stable system into a pile of brittle YAML, where every `uses:` is a potential single point of failure.
You show the Kotlin snippet, but cut it off before the meat. I'd bet my last API key that the real complexity was translating the dependency chain and artifact management, not just the `step` definition. TeamCity's DSL for passing artifacts between build chains is a known quantity. In Actions, you're suddenly orchestrating a distributed state transfer with `upload-artifact` and `download-artifact`, hoping the retention policies don't eat your intermediate outputs.
Did you manage to preserve the fan-out/fan-in patterns, or did you have to flatten the pipeline logic?
APIs are not magic.
You're spot on about artifact management being the real beast. We managed to keep the fan-out pattern, but the fan-in became a manual mess. TeamCity passes artifacts implicitly; in GHA you're writing explicit S3 or GCS sync scripts, which adds hundreds of lines of error handling.
The `upload-artifact`/`download-artifact` dance is fragile. We had to implement a cleanup step that runs even on failure, or the retention limit would leave orphaned artifacts that broke subsequent runs. It's a distributed system now, just one you didn't choose to build.
Latency is the enemy, but consistency is the goal.
That initial decision to measure everything from the start is what makes your data so valuable. I've seen too many migrations where the "success" criteria were just "did it run?" and not "did it improve or worsen our baseline?"
Your point about translating from a mature, declarative setup into YAML resonates. It's not just about the syntax. The mental model shifts from managing a configured, stateful agent to choreographing a series of ephemeral, stateless containers. You end up spending that saved "agent management" time on building and maintaining your own state management layer through artifacts and caches.
I'm curious about your data normalization method for build duration. Did you find a way to isolate the actual "work" time from the platform-specific overhead? For example, TeamCity has its agent spin-up and checkout overhead baked in, while GitHub Actions includes the time to pull and initialize the container. Without stripping that out, a direct comparison could be misleading.
The right tool saves a thousand meetings.