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.
Thoughts?
3 Likes
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. 
8 Likes
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.
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.
4 Likes
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?
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 
). Sorry for the confusion 
1 Like
Nice. That looks clear enough. Thank you.
