dc0d
Problem Using ExCoveralls When There Are Specs In Code
In short, when the specs are removed from lib/excoveralls_spec_lab/kata/user.ex , then the command mix coveralls.html works without a problem and generates the output html file cover/excoveralls.html .
But if there are any specs in lib/excoveralls_spec_lab/kata/user.ex , then the command mix coveralls.html will show this error:
** (exit) an exception was raised:
** (MatchError) no match of right hand side value: :error
cover.erl:1591: :cover.do_compile_beam2/6
cover.erl:1483: :cover.do_compile_beam/3
(stdlib) lists.erl:1239: :lists.map/2
cover.erl:2911: anonymous fn/2 in :cover.pmap_spawn/4
cover.erl:600: :cover.call/1
lib/excoveralls.ex:32: ExCoveralls.start/2
(mix) lib/mix/tasks/test.ex:351: Mix.Tasks.Test.run/1
(mix) lib/mix/task.ex:331: Mix.Task.run_task/3
lib/mix/tasks.ex:54: Mix.Tasks.Coveralls.do_run/2
(mix) lib/mix/task.ex:331: Mix.Task.run_task/3
(mix) lib/mix/cli.ex:79: Mix.CLI.run_task/2
Elixir and Erlang versions:
erlang 22.0.1
elixir 1.8.2
Sample repository for reproducing the issue can be found here.
An issue is also opened for this.
Marked As Solved
Also Liked
bdubaut
Hi, thanks for this discussion, as it seems I am not the only one with this issue. I’m getting the same type of error in an umbrella project. I have 4 apps in there, things are working fine, but one of the apps crashes.
here’s my circleci job:
version: 2.1
jobs:
test:
docker:
# Codecov uses bash, and bash is not installed on alpine containers.
- image: elixir:1.9
- image: circleci/postgres:11
- image: rabbitmq:3.7-alpine
environment:
MIX_ENV: test
steps:
- checkout
- run: mix do local.hex --force, local.rebar --force
- run: mix do deps.get --only test, deps.compile, compile
- run: mix do ecto.create --quiet, ecto.migrate
- run: mix coveralls.json
- run: bash <(curl -s https://codecov.io/bash)
Coveralls is properly configured (it worked fine before). The only thing that is different is that I’m using the CQRS/ES framework commanded from @slashdotdash . It fails both on CI and locally, pointing again at the issue with the :cover module (however I’m running with erlang 22, not 17 as it’s stated in the github issue linked earlier in the thread).
The error I get is roughly the same as shown before:
==> domain
Cover compiling modules ...
** (exit) an exception was raised:
** (MatchError) no match of right hand side value: :error
cover.erl:1591: :cover.do_compile_beam2/6
cover.erl:1483: :cover.do_compile_beam/3
(stdlib) lists.erl:1239: :lists.map/2
cover.erl:2911: anonymous fn/2 in :cover.pmap_spawn/4
cover.erl:600: :cover.call/1
(mix) lib/mix/tasks/test.ex:12: Mix.Tasks.Test.Cover.start/2
(mix) lib/mix/tasks/test.ex:407: Mix.Tasks.Test.do_run/3
(mix) lib/mix/task.ex:331: Mix.Task.run_task/3
(mix) lib/mix/project.ex:352: Mix.Project.in_project/4
(elixir) lib/file.ex:1542: File.cd!/2
(mix) lib/mix/task.ex:431: anonymous fn/4 in Mix.Task.recur/1
(elixir) lib/enum.ex:1948: Enum."-reduce/3-lists^foldl/2-0-"/3
(mix) lib/mix/task.ex:430: Mix.Task.recur/1
(mix) lib/mix/project_stack.ex:208: Mix.ProjectStack.recur/1
lib/mix/tasks.ex:54: Mix.Tasks.Coveralls.do_run/2
(mix) lib/mix/task.ex:331: Mix.Task.run_task/3
(mix) lib/mix/cli.ex:79: Mix.CLI.run_task/2
(elixir) lib/code.ex:813: Code.require_file/2
In order to solve this, I had to remove all typespecs from my commanded app. This brings another question to me:
Where is the problem really coming from?
I can think of a few possiblities:
- there still is an issue with the
:covererlang module - there is an issue with the Mix interoperability with the
:covererlang module - my typespecs were bad, although dialyzer was not complaining
- there is an issue with the
excoverallspackage
I would love to move this problem forward, but I feel a bit lost now. Does anyone have an idea?
EDIT
I was able to fix the issue by declaring types in the files that were supposed to:
@type t ::%__MODULE__{}
putting this in the modules that required it fixed everything. I think it’s important to note that this was an issue as long as the missing types were used as arguments of the function being specified, things were fine if the return type of a function had not been specified at all in its module.
this is still a mystery to me, but at least I found a way to fix it.







