7 ms·

Jenkins has always rubbed me the wrong way. The quality of plugins, the dated UI, Groovy. It just feels out of place and bloated every time I use it. Being a Ja

Jenkins has always rubbed me the wrong way. The quality of plugins, the dated UI, Groovy. It just feels out of place and bloated every time I use it. Being a Java app doesn't help either. It reminds me of Jira where you have to hack that death to make it "fit in" to common workflows. I'll take any of the alternatives over it.

radicaldreamer 5y ago
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.
- maccard 5y ago
  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.
  - lmm 5y ago
    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).
    - maccard 5y ago
      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?
      - lmm 5y ago
        > 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.
      - Sympho 5y ago
        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.
- MuffinFlavored 5y ago
  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"?
  - emanuelez 5y ago
    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.
- js2 5y ago
  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/ http://screwdriver.cd/
  - Aeolun 5y ago
    The problem is that website presents me almost zero information about the product.
- theptip 5y ago
  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.
  - handrous 5y ago
    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)".
    - Aeolun 5y ago
      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.
2OEH8eoCRo0 5y ago
What are good alternatives?
- eddieh 5y ago
  http://buildbot.net/ http://buildbot.net/
  - buildbot 5y ago
    Oh no my username is a an actual product :/ Though this looks pretty awesome!
    - ArchOversight 5y ago
      Buildbot as a project has been around since 2003... with a username like that I am surprised you hadn't heard of it before! Buildbot was the first CI I ever deployed at a company a long time ago. It came before Jenkins!
- sneak 5y ago
  I like Drone, and run it on my own systems. It integrates nicely with Gitea.
  - 0xbadcafebee 5y ago
    Drone Enterprise is fantastic. Rough around the edges and the docs are really lacking, but it's just so god damn simple and effective.
  - 0xcoffee 5y ago
    Links for the lazy: https://www.drone.io/ https://www.drone.io/ https://github.com/drone/drone https://github.com/drone/drone
  - athenot 5y ago
    +1 for drone. Note that it's intended for dockerized deploys, so it won't fit if you're not deploying containers.
lelandbatey 5y ago
To throw my hat into the ring: I've found the best "runnable jobs" / "digraph of jobs" system I've ever used to be Gitlabs built in CI system. The UI is nice, it's got tight integration into our existing code workflows meaning there's a close-but-not-too-close association between code and jobs meaning it's easy to say that "the code and the jobs running that code live 'in the same place'" if you want that, and it still provides all the pipeline features you'd want if you want to use your CI/jobs as a cornerstone of your infra; features like the ability to schedule pipelines, to trigger pipelines via other pipelines, remote triggering of pipelines via cURL request, pipeline DAGs for a 'make-like' build experience, etc. I've absolutely loved using Gitlab CI for the last several years, and I highly recommend it.
- epage 5y ago
  My experience is the opposite. Gitlab has a lot of features but they are all half-baked. Ever time I try out a feature, I feel like I get bit for doing so. 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.
  - nawgz 5y ago
    > At first child pipelines couldn't access artifacts from the parent job 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.
NikolaeVarius 5y ago
I hate jenkins groovy so much
- nobleach 5y ago
  Yeah, Jenkins can be really unpleasant. Groovy as a language isn't so bad - I just don't use it anywhere else. So... like a few other languages, I have to look things up every time I need to mess with it.
encoderer 5y ago
We (Cronitor) are seriously considering diving in here. People already install Cronitor to remotely monitor their background jobs, we have a lot of the UI and data platform challenges solved, and we are building a control plane to allow you to securely invoke your jobs remotely (via polling). I'm not totally convinced we should go this path vs better and deeper monitoring and metrics capabilities, but we're contemplating it because, honestly, Jenkins needs to be replaced. (Readers, if that sounds interesting, and you have some Kubernetes and Golang experience, we are hiring!)

radicaldreamer 5y ago

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.

maccard 5y ago
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.
- lmm 5y ago
  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).
  - maccard 5y ago
    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?
    - lmm 5y ago
      > 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.
    - Sympho 5y ago
      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.
MuffinFlavored 5y ago
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"?
- emanuelez 5y ago
  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.
js2 5y ago
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/ http://screwdriver.cd/
- Aeolun 5y ago
  The problem is that website presents me almost zero information about the product.
theptip 5y ago
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.
- handrous 5y ago
  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)".
  - Aeolun 5y ago
    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.

2OEH8eoCRo0 5y ago

What are good alternatives?

eddieh 5y ago
http://buildbot.net/ http://buildbot.net/
- buildbot 5y ago
  Oh no my username is a an actual product :/ Though this looks pretty awesome!
  - ArchOversight 5y ago
    Buildbot as a project has been around since 2003... with a username like that I am surprised you hadn't heard of it before! Buildbot was the first CI I ever deployed at a company a long time ago. It came before Jenkins!
sneak 5y ago
I like Drone, and run it on my own systems. It integrates nicely with Gitea.
- 0xbadcafebee 5y ago
  Drone Enterprise is fantastic. Rough around the edges and the docs are really lacking, but it's just so god damn simple and effective.
- 0xcoffee 5y ago
  Links for the lazy: https://www.drone.io/ https://www.drone.io/ https://github.com/drone/drone https://github.com/drone/drone
- athenot 5y ago
  +1 for drone. Note that it's intended for dockerized deploys, so it won't fit if you're not deploying containers.

lelandbatey 5y ago

To throw my hat into the ring: I've found the best "runnable jobs" / "digraph of jobs" system I've ever used to be Gitlabs built in CI system. The UI is nice, it's got tight integration into our existing code workflows meaning there's a close-but-not-too-close association between code and jobs meaning it's easy to say that "the code and the jobs running that code live 'in the same place'" if you want that, and it still provides all the pipeline features you'd want if you want to use your CI/jobs as a cornerstone of your infra; features like the ability to schedule pipelines, to trigger pipelines via other pipelines, remote triggering of pipelines via cURL request, pipeline DAGs for a 'make-like' build experience, etc. I've absolutely loved using Gitlab CI for the last several years, and I highly recommend it.

epage 5y ago
My experience is the opposite. Gitlab has a lot of features but they are all half-baked. Ever time I try out a feature, I feel like I get bit for doing so. 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.
- nawgz 5y ago
  > At first child pipelines couldn't access artifacts from the parent job 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.

NikolaeVarius 5y ago

I hate jenkins groovy so much

nobleach 5y ago
Yeah, Jenkins can be really unpleasant. Groovy as a language isn't so bad - I just don't use it anywhere else. So... like a few other languages, I have to look things up every time I need to mess with it.

encoderer 5y ago

We (Cronitor) are seriously considering diving in here. People already install Cronitor to remotely monitor their background jobs, we have a lot of the UI and data platform challenges solved, and we are building a control plane to allow you to securely invoke your jobs remotely (via polling). I'm not totally convinced we should go this path vs better and deeper monitoring and metrics capabilities, but we're contemplating it because, honestly, Jenkins needs to be replaced. (Readers, if that sounds interesting, and you have some Kubernetes and Golang experience, we are hiring!)