5 ms·

CircleCI is fine for the private repositories of work projects, but not for public libraries. In trying to migrate a fairly popular open source library I maint

CircleCI is fine for the private repositories of work projects, but not for public libraries. In trying to migrate a fairly popular open source library I maintain to CircleCI, from TravisCI, I bumped in the following two problems: 1. setting up a build matrix with various configurations (JVM version, compiler version, coverage on or off, etc) is a pain in the ass (possible, but a pain nonetheless), a configuration that TravisCI has nailed 2. basic functionality, like triggering a notification on Gitter via a simple HTTP hook when the build has finished, does not work I do love CircleCI for our work project, as it doesn't need a build matrix or notifications to Gitter and thus was fairly easy to setup. But I also love to see some competition for my public projects.

weberc2 7y ago
We’ve had to build a lot on. Like support for passing state across jobs in a workflow, or branching, or triggering a workflow with parameters, or triggering a workflow from a different branch, or etc. CCI went to unnecessary lengths to not support obvious use cases, or that’s how it feels. :(
- davnicwil 7y ago
  I've been there and spent hours if not days shaping builds and using workarounds/hacks to fit the esoteric manner in which CI services need your builds to run (setting up the build pipeline as a series of containers but without easily accessible persistent storage between the containers seems to be the current popular model - which is the case because it's very easy for a service provider to provide and manage the compute this way but pushes all the work onto you instead to get it working). This problem is what I'm trying to solve with https://boxci.dev https://boxci.dev for myself and hopefully others too. The idea is it'll do all the management stuff that a CI service should do, but let you run the actual builds however and wherever you like, on your own machines, using an open-source cli. Check it out, perhaps you'll find it useful. It's launching very soon!

weberc2 7y ago

We’ve had to build a lot on. Like support for passing state across jobs in a workflow, or branching, or triggering a workflow with parameters, or triggering a workflow from a different branch, or etc. CCI went to unnecessary lengths to not support obvious use cases, or that’s how it feels. :(

davnicwil 7y ago
I've been there and spent hours if not days shaping builds and using workarounds/hacks to fit the esoteric manner in which CI services need your builds to run (setting up the build pipeline as a series of containers but without easily accessible persistent storage between the containers seems to be the current popular model - which is the case because it's very easy for a service provider to provide and manage the compute this way but pushes all the work onto you instead to get it working). This problem is what I'm trying to solve with https://boxci.dev https://boxci.dev for myself and hopefully others too. The idea is it'll do all the management stuff that a CI service should do, but let you run the actual builds however and wherever you like, on your own machines, using an open-source cli. Check it out, perhaps you'll find it useful. It's launching very soon!