Experience with Cirrus CI?

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.

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.

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

cache:
  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.

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

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

osx_check_task:
  osx_instance:
    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.

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.

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