gmile
I’d like to run a release with a “cover” information compiled in, run the application for a few days to collect the cover info to identify dead code in a legacy codebase. Optionally, doing so could help see what are the hot code paths in the app.
I’m not familiar with :cover module of Erlang, but based on the OTP27 release notes, cover has became quite fast, so I’m willing to risk running an app with :cover-compiled modules on a production workload.
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
axelson
If you try this out I’d love to read about how it goes!
gmile
And of course I forgot to add a question…
What would be the steps to build such a release with such info? Has anyone done anything like this and willing to share their experience?
gmile
Had some time to look into it and got coverage info in a production release. Was able to run coverage analysis, however failed at getting a nicely formatted coverage report files because source code for modules is missing in the release.
Not sure how to include source code in the final release. Maybe someone knows? Until then, I’ll
document everything I did so far. Here are the steps:
Add
:tools: to a list ofextra_applicationsinmix.exs:Specify a
strip_beamsoption in thereleasessection ofmix.exs:The
strip_beamsoption is documented here.Keeping just the
Dbgichunk appears to be sufficient for:coverto work, but the full list of so-calledchunkIDs can be found here.Compile, then start the release and connect to a remote console:
Execute this line:
Here,
/app/lib/myapp-1.0.0/ebinis a path whereebinfiles for a release are stored. This line is inspired by the following snippet from the Elixir source code: link.For the command to finish it took a good several seconds on my M3-based MacBook to process ~350 modules.
That’s it, the modules are now
:cover-compiled. But you can confirm this once again by running this:At this point, I can make the application do some work, like serve HTTP requests during execution of an e2e tests suite.
Finally, see the results by connecting to the release remotely and running
:cover.analyse(). The output will lookssomething like this:
Notes:
Sadly, as I mentioned, I couldn’t make saving the analysis to an easily digestable file format work. That is, attempting to run
:cover.analyse_to_file()will produce output that looks like this:The documentation for
:cover.analyse_to_file/2mentions locations where the function will look for source code. But I couldn’t quickly find how to makemix compileormix releaseinclude the source code of the application together with the release. Bluntly copying source code files into one of the folders where:coverexpects it likely won’t work, since the source code is written in Elixir, while:coverexpects source code in.erl? I don’t know and haven’t tried this.“Performance” section on “cover - The Coverage Analysis Tool” page in Erlang documentation has this to say:
It’s an important note and I haven’t had the chance to do more tests & comparisons to understand exactly how slower / resource-hungry the app becomes.
gmile
Figured out how to generate the .html reports:
While connected to a release remotely, generate export:
Copy the export file to the root of application source code (e.g. the to folder that contains
mix.exs,mix.lock, etc.),Prepare a folder to save .html reports into. Run:
Run
iex -S mix, then run the following commands:The reason
:cover.analyse_to_file/1works this time is because it’s able to locate source code by callingMyModuleName.module_info(:compile)(as described in documentation for:cover.analyse_to_file/1.Sadly, the contents inside
.htmlfiles look like this:E.g. a weird
:-(symbol and no green lines whatsoever, as well as completely missing execution counter info. So, I must be doing something wrong stillgmile
Figured what the problem was - need to compile the modules first, only then import the
:coverdata. Here’s the correct sequence to produce the .html report:As an example, calling functions
CoverTest.one(),CoverTest.two()andCoverTest.three()produce the following output - e.g.IO.puts("Hello, world!")was executed 3 times:binarytemple
Great write up, I’ll be giving this a try