async_do with arguments is useful for debugging a particular suite/test
with r3:break()
Example session:
Add r3:break() in recompile_when_hrl_changes test in test/rebar_compile_SUITE.erl
rebar3 shell
...
1> r3:async_do(default, ct, "--suite=test/rebar_compile_SUITE.erl --case=recompile_when_hrl_changes").
ok
Running Common Test suites...
%%% rebar_compile_SUITE:
=== BREAK ===
2> r3:resume().
ok
3> .
All 1 tests passed.
Windows does not have the same quoting rules as Unix so
we need to use platform independent quoting. Also for
os:cmd like operations we do not expect the program to
read any input so in order for it to work on windows we
should put -noinput there.
In r3_hex_core.erl we set default hex config. For example, we set the
api_organization to be undefined. By merging the hex auth config into
the default config this way round we allow users to override the default
config.
This will allow project with larger dependencies sets to clean only the
apps they want to when testing or changing small things, rather than
forcing a rebuild of the whole dep set.
Also allows cleaning up apps, not just deps.
Fixes#2159; this is done by force-reloading the handlers to match the
config.
This can create a bit of a funny effect if sys.config specifies an INFO
log level (or lower) is specified. While apps are booted for config
changes before the cth_failonly hook is enabled, supervision and other
application log messages can start being output. They will start being
suppressed once the CT run begins.
This is not a bug, it's a race in instantiation of control and enabling
of log levels. Nothing we can do about that. It might however surprise
people a good bit. If non-default stdout handlers are added, they are
similarly likely to become noisy; specifying a test-specific sys.config
file may be necessary then.
Also includes a bump of cth_readable version, which now checks for
updates to the log formatter on every test output.
To avoid a conflict the Kernel's default handler have to be disabled
before the new default handler is added
{kernel,
[{logger,
[{handler, default, undefined}
]}
]},
{my_app,
[{logger,
[{handler, default, my_handler, #{}}
]}
]}
To support this behavior in shell it's necessary to process the
handler-default-undefined tuple.
It's not clear what to do with the simple handler (logger_simple_h)
however. It's added at the start and removed if a default handler was
added. Should it be added in reread_logger_config/1 if there's no
default handler?