i’m facing a strange issue that I cannot really understand.
I’m using an erlang library in my elixir project: https://github.com/lehoff/chronos
which works as expected, also in tests and so on. Nothing strange here.
But in travis I consistently get “module :chronos is not available”, even if from the logs it gets
fetched (since is a mix dep) and compiled.
(for example https://travis-ci.org/xadhoom/detectino-core/jobs/174918405 )
In my environment this error never happened, even with a fresh checkout of my project (just
to avoid some missing deps clean or whatever)
Elixir is 1.3.4 and OTP 19.1.
Any pointer where to check? Happens only with that specific module.
I can’t see it beeing downloaded in the logs, but since you are caching your deps folder I will assume that the cache is valid and complete.
I also took a look into your project on github and was not able to find a place where you actually start the
Have you tried to explicitely list it in your dependent applications?
I did a deeper dive into this…
MIX_ENV=test; mix deps.get && mix deps.compile && mix coveralls.travis --umbrella
This line of your script does set your
:test for the next shell command, which you end instantly by saying
;, everything beyond that is ran in its default environment.
In general I’d prefer to write that line as
MIX_ENV=test mix do deps.get, deps.compile, coveralls.travis --umbrella
Besides the fact that this saves you some forks on the shell level, this makes also sure, that all commands are run in the same
I have made a PR with this changes, we will see if this does fix it when travis has run.
Yes, the cache is ok, and obviously also cleaned it to debug.
the :chronos app does not need to be run, since is a gen_server started where is needed.
If you check, this is also a compilation issue (it complains on compilation), so is pretty obvious that it will fail on run.
Well, yes you’re right, is an error but makes no difference, because mix coveralls launches mix test which sets the env to test by default.
It was just a (wrong) try because I was out of ideas.
Well, at least my PR reduced the number of times
:chronos was mentioned in the logs from 10 times to 6 times. Also I am still experimenting.
I can’t experiment locally though, since I have troubles compiling
:idna under windows.
And I am out of ideas and time for now. Probably I will have time again in a couple of hours if noone was able to help you until then.
I just realized that your dependency is using a make file instead of rebar, perhaps your problem is related to this fact?
Please try to build it directly using mix deps.compile chronos before running the tests and make sure you do it for test env.
Well, seems that I found out the issue ( replicated here https://github.com/xadhoom/cronos_test ).
Basically, forcing the REBAR_DEPS_DIR which is needed to compile another dep https://github.com/tonyrog/can breaks the :chronos inclusion.
Maybe is related to the makefile you noted, will verify it in the test repo.
REBAR_DEPS_DIR=$TRAVIS_BUILD_DIR/deps is the one that breaks :chronos.
I think I need to figure out what is going on in both packages (:can and :chronos) now.
@NobbZ thanks for the pointers
I think the best but not easiest way were to convince all make file apps to use rebar3 instead.
A proofed-to-work PR might help with this.