Hacker News Reader

Comment by radicaldreamer | Hacker News Reader

Despite everything you said being true, it's still one of the few open-source, free solutions in the mobile build space.

I'm wondering if Buildkite or something newer is comparable today, but for a long time, Jenkins was one of the only non-custom ways of building an in-house iOS/Android build system.

View on HN

At Yahoo (Verizon Media), the CI/CD team started with Jenkins, then built a UI to manage all the instances, then wrote their own engine that replaced Jenkins entirely. It’s a good product:

http://screwdriver.cd/

The problem is that website presents me almost zero information about the product.

Is there something about mobile builds that makes the standard Jenkins competitors like GitLab, Drone etc. unsuitable?

Even hosted Gitlab (gitlab.com) lets you bring your own runner to use whatever arch you need to run the jobs on.

I’m sure I’m missing something here though.

Large cross-platform native builds generally, not just mobile, kinda suck on the usual cloud solutions. The cloud stuff's amazing, performs well-enough, and is easy to configure if your workflow is... containers, and that's all. It gets rough in a hurry once you're much outside that, and especially with large (=long build time) apps. Many can accommodate native builds, but for anything non-tiny you'll experience slow builds or go over plan limits (and see spending skyrocket) in a hurry. Anything that requires large assets at build-time, or anything else for which it's nice to have persistent state between builds, is right out. You'll end up spending a bunch of time (=money) re-configuring your build to fit the tools, so performance is merely bad and not astonishingly, uselessly bad.

You're also more likely, with native builds on cloud CI, to run into "yeah, we support that! (I mean... we shipped it, anyway, pay no attention to all the bugs and rough edges)".

The thing is, none of that is true. Even for the cloud hosted providers (Gitlab at least) you can install your own native runner and connect it to your CI system. Then run any weird combination of commands you want.

I've not used buildkite (we don't use git), but we're moderately happy with TeamCity. It's definitely not perfect, but it's orders of magnitude better than Jenkins.

TeamCity is expensive and when we evaluated it we hit a significant bug that they couldn't fix (if you rebuild a snapshot build from early in a long chain of snapshot dependencies, it would run a quadratic number of rebuilds rather than rebuilding everything once in topological order as Jenkins does).

I've found TeamCity's pricing to be pretty reasonable; It's free to start, $300 per extra agent after 3 agents, or $2500/year for support with 5 build agents (which is where we're at right now). It's also 50% off for startups. Compared to any other bring-your-own-agent solution, it's very reasonable.

The dependency bug sounds rough; have you got a youtrack link to it by any chance?

> I've found TeamCity's pricing to be pretty reasonable

Well, compared to Jenkins it's very expensive :). I guess the cheaper options may be newer, or maybe that employer ran the evaluation in a dysfunctional way (wouldn't be the first time). All I can say is that was a consideration for us.

> The dependency bug sounds rough; have you got a youtrack link to it by any chance?

No, this was three jobs ago and was all handled verbally with their representative (who gave off a pretty unprofessional vibe, frankly, so may not have recorded it in youtrack even if that's their policy). If you want to test it out, set up something like 10 maven projects with SNAPSHOT versions all depending on each other, and set to rebuild on commit or when their dependencies change: B depends on A, C depends on B (and so implicitly on A), D depends on C (and so implicitly A and B), etc.. And then commit a change to A and see what happens. Whether you think this is a good way to set up your projects or not, it's what we were doing at that place, and Jenkins handles it fine (it will rebuild A, B, C, ... in order) whereas TeamCity (at least when we were evaluating it) will rebuild A, then rebuild B-L, then rebuild C-L because B has changed, and so on.

It's even better than that, because you can pay just once and stay on the same version forever, as long as you don't need new features and support. And JetBrains gives 50% discount for license renewals, which makes it not $2500 but $1250/year – I believe this applies to all JetBrains products, not only TeamCity.

I could be wrong but isn't Jenkins at its core just "wait for a job trigger (git push/commit to remote origin), then run some shell scripts"?

Not really. Jenkins allows a very fine control over jobs and steps orchestration. I realize it might appear as a dated glorified cron, but it's really not. There's nothing you cannot do with it, which is more than I can say about any other CI system I used.

Reply on news.ycombinator.com