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.
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.
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 dependency bug sounds rough; have you got a youtrack link to it by any chance?
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.
I've absolutely loved using Gitlab CI for the last several years, and I highly recommend it.
A couple of cases
- At first child pipelines couldn't access artifacts from the parent job. Now you can opt-in to it but nothing enforces sequencing
- Some features only work with "needs" (getting parent pipeline artifacts) while others only work without it (depending on an entire stage)
- When a job you "needs" doesn't exist, instead of having a sane behavior (e.g. skip yourself), the pipeline errors. Correctly propagating and maintaining all of the rules correctly in a moderately complex pipeline is ... difficult.
Why would you use the tool like this? Make jobs / blocks that generate artifacts, and then chain them together into a workflow so there isn't hierarchical issues.
Now, maybe I am working in a simplistic world, but: the only time I have parent / child relationships is when a repo or service is built and another pipeline is invoked to run integration tests or deployments. What situations have lead you to needing to pass artifacts between pipelines and not job stages?
> When a job you "needs" doesn't exist, instead of having a sane behavior ... the pipeline errors
You and I may work in very different worlds, but I personally would be quite offended if a dependency graph workflow executor saw a node with an explicitly specified dependency missing and proceeded to NOT error.
(Readers, if that sounds interesting, and you have some Kubernetes and Golang experience, we are hiring!)
I personally found both of those to be paradigm shifts (I went from Hudson to Jenkins to Travis CI to GitLab to GitHub Actions). Travis CI introduced self-serve test infrastructure configuration-as-code, GitLab introduced composability and API integration, GHA introduced many more API features (like various kinds of event sources) and better composability. Each transition also took more hosting headaches and compatibility issues off my hands.
I definitely prefer TC over Jenkins though. The Jetbrains support for TC is also really good and they have been helpful whenever we contacted them or opened an issue on their public tracker.
It has a Kotlin DSL that is quite powerful and flexible, but of course you need to know your way around Java to make the most of it.
Custom plugins is also an option if you need something special that is not provided out of the box.
Even though I have moved on to Azure DevOps Services, it's still good to see that JetBrains have fixed a 10 year old feature request.
It takes some getting used to, but I really got to love its concepts for resources/inputs/outputs and how they work together to get you actually reproducible builds.
Edit: Took a look again: The situation might have gotten better since I last played with concourse
Because the ci system is aware of your tests, and perhaps a filename/test description, it can keep stats on them over time.
This is an ancient version of teamcity [0], but it shows how it knows how many tests were run, how many passed, and that there's one "new" failure in this run vs previous runs.
This lets it tell you which tests are slow, which are flaky, all sorts of history of those wrt to state of the associated repo, etc.
Not having these sorts of things once you have them is like flying blind.
Seems to be a bit harder to integrate with other systems (like GH check results), and alas the community is pretty small (which probably factors into the first point).
Note that it's intended for dockerized deploys, so it won't fit if you're not deploying containers.
Sure there is something missing for more elaborate build pipelines, but not enough missing to block you.
The best think about gitlab vs Jenkins is that there are no plugins. So it’s very clean what is gitlab and what is your config of it.
Whereas Jenkins has so many plugins and config for the plugins that it’s hard to say where Jenkins ends and your build pipelines begin.
Though this looks pretty awesome!
Buildbot was the first CI I ever deployed at a company a long time ago. It came before Jenkins!