Add support for Elixir/Erlang


#1

It’d be great to have official support for Elixir/Erlang. Although it’s workable with a custom circle.yml, it would feel so much smoother (and like Circle) to have it work out of the box.

Thanks!


Building Elixir Projects
#2

CircleCI includes Erlang r14b04. That’s really old. The current version of Erlang is 18.3.

I don’t know why CircleCI doesn’t seem to understand that developers want to be able to use the same version of a language in testing as in development and production.

What should be a matter of putting a version number in a config file or just defaulting to the latest stable version instead took at least half a day. Figuring out how to install current versions of Erlang and Elixir with asdf, how to cache the right directories, and this isn’t my first time doing a custom CircleCI file.

That time is multiplied by every developer that wants to use these languages.

It’s the same thing for the Go language, where Go 1.6 has been out for nearly 2 months but CircleCI is stuck on 1.5.3.

See:



#3

Here’s another tool to install arbitrary versions of Erlang:


#4

I agree. It would be great to have native support to Erlang/Elixir. Travis CI already have.


#5

Also raising my hand for native Erlang/Elixir support


#6

Not having erlang/elixir readily available greatly increased development time for a project of mine a few months ago. My company had to implement custom install scripts, testing scripts, and more. Unfortunately, they were brittle and prone to breakage, so many hours were spent refining them. Eventually, it got to the point where we just gave up and stopped using CircleCI for the project.

Please include it.


#7

This is a big deal for us too. Not having native Elixir support has us exploring other CI options.


#8

Native support for Elixir/Erlang means a great deal to us as well.

The current Erlang version is a joke. It would be actually better to include none.


#9

+1 for native Erlang/Elixir support.


#10

This would be a great addition!


#11

+1 for Native support with Elixir/Erlang


#12

This is starting to become an issue… we are considering activating a Travis account again as they seem to have figured this out… :frowning:


#13

FROM elixir in Docker will now pull Elixir 1.3.1 and Erlang 19.0.1. So far I haven’t had success running tests in Docker containers on CircleCI, but it seems like a fairly good approach to me.


#14

+1 for Elixir/Erlang support. Might switch back to Travis because it is much easier to install and maintain Elixir builds with them.


#15

+1 for Elixir support.


#16

Thanks everyone for all of your feedback. I’ve been following this thread closely. I have a couple of questions.

Aside from inference, what does it mean (to you) to have first class support for Exlixir? Version manager, pre installed dependencies, etc?


#17

@levlaz having access to the Elixir 1.x versions would be important. So Elixir 1.0 - 1.2 along with the patch versions. I don’t think any external deps need to be installed by default as we can run installation of these during our own setup. As long as we can cache these dependencies as well as their compiled files (deps/ and _build/) that should lead to a speedy CI setup


#18

@levlaz With regards to “what it means” to have first class support for Elixir, I think there are a couple things:

  • any first-class support of Elixir is inextricably entwined with first-class support for Erlang/OTP, since Erlang/OTP provides the run-time system
  • for me, first class support entails the same level of version choosing as you provide for other languages, namely the ability to specify the version at runtime; however, as mentioned in my first bullet point, this should allow for specifying both the Erlang/OTP and the Elixir version to run against, for example
machine:
  elixir: 1.3.2
  erlang_otp: 18.3
  • for inference of the Elixir version at least, the mix.exs should specify a version requirement for Elixir (like ~> 1.3) that would have to be interpreted. However, I do not believe this specified an Erlang/OTP version. In that case, it may be best to infer the current stable release.
  • it would be good to have the hex and rebar dependency managers already bootstrapped into mix, the Elixir build tool that is installed alongside Elixir (traditionally this is automated by running mix local.hex --force followed by mix local.rebar --force to bypass the interactive parts);
  • as @bcardarella mentioned, having versions of Elixir 1.x and above available would be great; as well, having at least Erlang/OTP 18.3 and 19.0 available.
  • having build-essential available since certain packages rely on C-based extensions that needs to be compiled

Open questions that I’m not qualified to answer:

  • Will installing HiPE support by default conflict with systems that don’t expect HiPE?
  • Should MIX_ENV=test be set by default?
  • Should the database phase perform mix ecto.migrate if the Ecto dependency is detected? (in this case, having MIX_ENV=test is important)
  • Will umbrella projects introduce any complexity that needs to be accounted for?

#19

I don’t believe it should as you may want to use schema load instead of migrating depending upon your use case.


#20

Agreed, as that’s actually what I need to do for my company’s codebase. The migration logic is still in Ruby, so Elixir tests are done against a schema-only restoration based on the last successful Ruby migrations.

However, as a default case it may be easier for “up and running” to have mix ecto.migrate as a default that satisfies 80% of use cases, and for users who have more complex requirements to use the override specification in circle.yml, e.g.:

database:
  override:
    - pg_restore -c -d circle_test -s priv/db/schema.db

I might be over-simplifying the issue at hand, though.