| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Support `profile_string` overlay var in releases
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | | |
Disable the default logger handler in shell if required
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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?
|
| |/
|
|
| |
See http://erlang.org/doc/man/ct_hooks.html#Module:on_tc_fail-4
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Fixing duplicate macro definition in umbrella edoc
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When in umbrella mode (or through multiple profiles), users can specify
macros for EDocs based on either the {def, ...} or the {macros, ...}
arguments.
This patch replaces the prior options merging for umbrellas to use the
rebar3 tup_umerge utils to remove identical duplicates while preserving
correct ordering, and manually merges the {macros, ...} definitions
while ke eping the correct precedence rules since these appear (given
their behaviour) to be all individually extracted and passed as `{d,
...}` to the compiler so that epp expands them. This compiler
function freaks out on any re-defined macros and explodes.
Do note that the macros with `{def, ...}` are edoc macros and do not
suffer from that issue, safely deduplicating multiple definitions.
|
| |/
|
|
|
|
|
|
| |
version 0.5.1 is a maintenance release of hex_core specifically for
rebar3 which contains a configuration update. Prior to v0.5.1 if no
repo_organization key was set this could result in a function clause
error. The behavior is to now set repo_organization to undefined in
this case.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
OTP kernel application use "logger_level" configuration for configuring
level in primary configuration.
rebar3 uses "logger_info" for this purpose - ths is little bit confusing
and probably mistake.
This commit will unify behavior between kernel and rebar3o
Fixes: 0303567d95f0 ("Reload logger config in shell")
|
| |\
| |
| | |
rebar3 dialyzer: Warn when debug_info is disabled
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
keep resources in new state used in plugins upgrade
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
Fix crash when a dependency is missing app.src file
|
| | | |
| | |
| | |
| | | |
Patch up and add tests on #2112
|
| | |\ \ |
|
| | | | | |
|
| | | |/ |
|
| |\ \ \
| | | |
| | | | |
Fix custom compiler mods typespecs, add edoc
|
| | |/ / |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds an additional loading and merging of options for EDoc using
the values from the top-level along with those specified in the
rebar.config of an umbrella application.
The app-specific config values are prepended to the global ones; this
can likely cause some problems with manual path handling, but is
unlikely to happen in practice and the rest seems to work fine based on
order
Fixes the issue in #2114
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Gracious loading of unloaded but blacklisted mods
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rebar3's shell allows people to set applications as blacklisted to
prevent them from being reloaded because that can cause crashes.
However, as part of its normal operations, rebar_paths unloads all
modules that are currently not "owned" by at least one process,
considering them safe to do so.
These two behaviours, put together, lead to an odd thing where some
modules are suddenly unloaded and not in path, and that can be
confusing.
This calls for a unification of both features. We could decide to be
pushing the complexity of rebar3's shell into rebar_path so it knows of
blacklists, but this would be a bad idea because rebar_agent already
owns all the damn hack.
So instead this fix adds an optional call within rebar_agent's
blacklisted applications handling that calls `code:ensure_loaded/1` on
their modules. This avoids forcing any code change that would cause a
crash, but reinstates unloaded paths that could be confusing.
Addresses some comments in #2013
|
| |/
|
|
|
|
|
|
| |
This allows to reduce the number of noise to only checking deps' app
files when they're built, rather than on every run.
Since main apps and checkouts are still compiled every time, the linting
takes place there and then with a higher frequency.
|
| | |
|
| | |
|
| |\
| |
| | |
add support for usage message after template is done
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
