Experience with Cirrus CI?

Does anyone have experience with Cirrus CI?

Currently we are using both AppVeyor (Windows) and Travis-CI (Ubuntu) in Elixir plus we are looking to add FreeBSD. I would love if we could unify those and Cirrus-CI seems like a good fit.



Nice. I haven’t, but I was just looking for a free macos (I prefer CircleCI but they charge for macos) offering so we could ditch Travis for at least relx (been having a number of annoying failures bc of travis) and probably rebar3 too, though less important. I’ll be giving this a try soon.

1 Like

Disclaimer: I’m working on Cirrus CI

Just added an Elixir example using the official Docker images to documentation: https://cirrus-ci.org/examples/#elixir

Feel free to try it out and report any issues. :raised_hands:


Cool. And mix_cache: is just “sugar” for:

  name: mix

So I can do rebar3_cache:?

Exactly. Just syntactic sugar for naming.

Works great, thanks!

Just using the community cloud but it seems pretty fast and configuration is simple.

    image: circleci/erlang:21
    folder: _build
    fingerprint_script: cat rebar.lock
    populate_script: rebar3 compile --deps_only

    image: circleci/erlang:21
    - build
    folder: _build
    fingerprint_script: cat rebar.lock
  test_script: rebar3 ct
      path: "_build/test/logs/ct_run.*/junit_report.xml"

    image: mojave-base
  install_script: brew install erlang
  test_script: |
    wget https://s3.amazonaws.com/rebar3/rebar3
    chmod +x rebar3
    ./rebar3 ct

Only issue, which I’ll properly submit once I verify my theory, is the cache seems to fail if there are symlinks in the directory being cached. So I had to split out the build task that caches from the test run, otherwise it tries to cache after everything has run and complains, Failed to calculate hash of /tmp/cirrus-ci-build/_build! read /tmp/cirrus-ci-build/_build/default/lib/relx/include: is a directorySkipping uploading of /tmp/cirrus-ci-build/_build!_build/default/lib/relx/include is a symlink.

I’m curious how fast is Cirrus. I’m very unhappy with our current CI, takes at least 3 full minutes to do a build (with cached dependencies).

@fedor Do you have an average time for such a normal Phoenix app finishes a build?

Don’t have such specific numbers but would love to compare. Are you looking it for an OSS project? Would love to collaborate to get such data.

1 Like

Not really, no. And most are pretty basic anyway so they can’t serve as benchmarks.

I’ll review your free tier (if you have any?) and ask further questions.

But what’s been a weak point of many CI services so far has been universally these two points:

  • Slow compilation. (Weak CPUs, slow disks, small amounts of RAM, all of these could be contributing)
  • No cached dependencies. This has been a major PITA in at least 3 services I tried in the last year.

Go ahead and feel free to ping me (@fkorotkov) on GitHub PRs! Cirrus is free for OSS and you can use up to 8 CPUs / 24G of RAM of memory for free with some generous concurrency limits. Paid plan with per-second billing can use up to 30 CPUs/ 90G of memory with no concurrency limits.

Cirrus also runs Google Cloud which shows awesome performance stability and I/O throughput (both internet and disk).

Caching is also inspired by how modern build systems do caching with an option to use an HTTP cache if your build system supports it.


Appreciate the openness and responsiveness! Thank you so much. :041:

EDIT: Do you guys have a calculator so we can try and get a rough idea how much would we end up paying monthly?

1 Like

BTW the Caching link points to a Gradle section? Maybe I am misunderstanding but how is this related to Elixir?

Ooops. Wrong link. Meant to point to Cache Instruction (forum doesn’t allow to attach a link to it but you can find it in documentation :thinking: ). Sorry for the confusion :sweat_smile:

1 Like

Nice. That looks clear enough. Thank you.