rebar3-exp.md

Rebar3 experience

• Common test issues
  • Couldn't get the ct setup working as we needed. Our ct command is: ct_run -pa ./_build/default/lib/*/ebin -logdir logs -suite test/${SUITE} -cover test/antidote.coverspec
  • Option -pa is not supported for rebar3 ct
  • Because of this we needed a Makefile which called ct_run manually. Makefiles were problematic for Windows users.
• Problems when switching branches
  • If the branch has different dependencies, the _build folder is not updated and rebar3 does not update it automatically on the next build
• Corrupt caches, bad error message (same as erlang/rebar3#1792)

======

For CT:

• the -pa _build/default/lib/*/ebin/ path should be covered automatically; what is not handled are custom paths outside of the build directory. So I have the following questions:
  • was the lib you wanted to access within the _build/default/lib/ directory but not accessible?
    • common issue here is making sure the dep is declared in the rebar.config file and not just accidentally in the directory
    • if the lib was outside of Rebar3's structure, we tend to recommend using ERL_LIBS=path/to/libdir as an env variable
• we do not respect the coverspec file as far as I can tell, but do automatic full-coverage of the local code with -c or --coveroption (the report for which can be obtained by running rebar3 cover)
• the logdir is within _build/ always to prevent having long ignore lists but --logdir option is supported
• --suite test/my_SUITE is supported.

For switching branches:

• This is actually one of the feature we like the most (auto-switching deps). See http://erlware.org/rebar3-features-part-5-dependency-branch-handling/ -- so I'm a bit surprised that it didn't work for you. Questions to help fix this follows.
• Were you checking in and tracking the rebar.lock file? Without that file, dependencies cannot automatically switch, so that would be the one explanation for the feature not working
  • old deps may remain in _build/ but they won't be added to the path unless they're in the lock file
• If you were tracking the lock file then we need to dig into this to figure it out

For corrupt caches and bad error messages:

• Point taken, that is a problem.
• We are currently rewriting part of the hex handling and so the cache will hopefully be a bit more reliable
• The error handling around logging and detecting the initial environment is indeed a bit weak