| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Getting real tired of that nondeterministic set of runs on OSX CI
|
| |
|
|
|
|
|
|
|
|
| |
The previous patch at #7c959cc fixed the usage of duplicate values
for directories through relative paths, but mistakenly went overboard
and dropped the `./` path, which is still fairly common. Similarly for
`../".
The code is modified to special-case such values and keep the code
working.
|
| |\
| |
| | |
fix sys config merging
|
| | | |
|
| |\ \
| |/
|/| |
Fix relative src_dir specifications to avoid double .app.src file detection
|
| | |
| |
| |
| |
| |
| |
| |
| | |
When fetching src_dir values, some relative paths can be inserted. When
deduplicating the paths on the fetch, this fact means that logically
duplicate (but literally different) directories can be returned at once.
By normalizing the names, duplication bugs can be resolved.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, this impacts profiles. It appears that relx as a whole
requires its configuration to be merged in one tuple order (New takes
precedence over Old), whereas the overlays require the opposite (Old
takes precedence over New) since the operation order on disk is
important to work well.
This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see #1609)
This is done while adequately maintaining the order of operations that
were required as part of #1563
Overlay vars of profiles are also checked to be working fine, along with
a test.
This fixes #1247 and #1609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a config file exists at the root of a project, defines a given
configuration value for a given profile, and that a sub-application
(umbrella app) also has the same profile defined with the same key (but
different values), the configuration values of the sub-application's
profile would get silently dropped.
The problem being that when the function to merge profiles is applied
recursively, it is applied to each profile (so it will merge on the keys
test, prod, etc.) rather than to each of the values of each profile.
This patch reworks the profile merging so that the current behaviour is
respected overall (a profile cannot be cancelled by a subdep's
non-existant profile since its value should have been ignored), but
ensures that sub-deps' profiles are otherwise applied recursively with
the proper rules:
- dependencies favor prior values
- plugins favor new values
- erl_first_files combine the lists
- relx uses the tuple merge algorithm
- erl_opts has its own custom merge as well
- otherwise the new value takes precedence
A test has also been added.
There is a risk of breakage in some applications that may have relied on
the buggy behaviour to work, though at this time we are aware of none of
them.
|
| |\
| |
| | |
Allow top-level apps to take precedence over deps
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The use case has been described in issue #1478 where a local application
can exist while being declared as a dependency as well. This allows, for
example, to work on a release where all applications may require to be
published independently, or to provide some form of 'vendoring' with a
local app.
The fix is done by decoupling the dependency source resolution form the
dependency parsing. The reason for this being that the discovery phase
needs to parse apps for their top-level deps, and dep installation needs
to resolve the packages with accuracy. In the current implementation,
both code paths call to the same function.
This patch splits up the precise discovery and makes it happen *only*
when installing dependencies, and only if a top-level app does not
already define the application needing resolving.
One weakness of this fix is that it necessarily breaks cycle detection
in dependencies that involve a root application depending on itself
since its own version as a dep will not be expanded. There appears to be
no possible way to prevent this, but should be rare enough to be worth
the tradeoff for the common case.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done through 3 main change groups:
- replacing `~s` by `~ts` in format strings, so that strings that
contain unicode are properly printed rather than crashing
- adding the `unicode` argument to all function of the `re` module to
ensure transformations on strings containing unicode data are valid
instead of crashing (see issue #1302)
- replacing `ec_cnv:to_binary/1` and `ec_cnv:to_list/1` with matching
functions in `rebar_utils`.
The last point has been done, rather than modifying and updating erlware
commons, because binary and list conversions can be a contentious
subject. For example, if what is being handled is actually bytes from a
given binary stream, then forcing a byte-oriented interpretation of the
data can corrupt it. As such, it does not appear safe to modify erlware
commons' conversion functions since it may not be safe for all its
users.
Instead, rebar3 reimplements a subset of them (only converting
atoms and chardata, ignoring numbers) with the explicit purpose of
handling unicode string data.
Tests were left as unchanged as possible. This may impact the ability to
run rebar3's own suites in a unicode path, but respects a principle of
least change for such a large patch.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When a given behaviour module does not exist, rebar3 brutally crashes.
This patch makes it so instead, there is a warning output menitoning the
missing behaviour, and this one is omitted from the unused function
calls check. This means that unused calls will instead be shown for the
module implementing a non-existing behaviour, as if no behaviour were
declared in the first place.
|
| |
|
|
|
|
|
|
|
|
|
| |
If xref analysis is being run by a dependency during its compilation
phase, the xref provider will try to add that deps' parents to the check
job while the ebin/ directories for them do not exist. This causes a
crash.
This patch makes it so directories are only added if they are existing,
preventing failure on any compile hook for dependencies and allowing
successful compilation as a best effort.
|
| |\
| |
| | |
reset hooks under profiles for application opts
|
| | | |
|
| |/
|
|
|
| |
This mostly moves a lists:reverse/1 which ensures that profile overlays
are run first but keeps the order of overlays otherwise.
|
| |\
| |
| | |
Allow profile deps upgrade
|
| | |
| |
| |
| |
| |
| | |
Prevents showing false upgrade messages when upgrading in a non-default
profile. Also shows an info message explaining default deps don't get
updated in a non-default upgrade.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This fixes the output of end_per_testcase crash notifications when the
test passes.
This also detect an issue of the kind with rebar_pkg_SUITE which is now
fixed.
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
The option {spec,Specs} is allowed in ct_opts, but
rebar_prv_common_test:test_dirs did not take into account that Specs
could also be a string only, i.e. not a list of strings.
|
| | |
|
| |
|
|
|
|
|
| |
The finding of the file was done based on an assumed 'src' path which
may not be correct. This patch instead replaces the value with a lookup
in configured paths and returns the first that matches to an existing
file.
|
| |
|
|
|
| |
First find the rebar.config file, and if any data is found, check for
src_dirs config. If nothing is there or no app is found, default to src/
|
| |
|
|
|
| |
This lets people who use custom directories layout without leaving the
.app.src in src/ to still see their app build.
|
| | |
|
| |\
| |
| | |
Allow exclusion of apps in cover
|
| | |
| |
| |
| |
| | |
Adds a new option `{cover_excl_apps, Apps}` to exclude apps from coverage
analysis by name.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
on 19.x forward the compiler should now take into consideration the value
of the environment variable `ERL_COMPILER_OPTIONS` when deciding whether
or not to recompile a module
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of a hard crash, display an error message indicating which app
failed.
We can't report the exact failure; only EDoc does it to stdout itself
and we can't capture it.
Pre/Post hooks are run properly despite the failure, as per escript and
compile providers.
|
| | |
| |
| |
| | |
to be roundtripped again to windows.
|
| |/
|
|
|
|
|
| |
Requires changing a bunch of arguments for xerocopy since it
does not allow to rename while copying.
Lots of tests added
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Parse given test specs and add all spec- and suite directories as
extra_src_dirs in order to ensure that all these directories are
copied to the _build area and the suites are compiled.
Specs located in the project- or app root are explicitly copied to the
_build area in order to avoid recursive copying of the complete
directory tree.
|
| | |
|
| |
|
|
|
|
| |
This is a bugfix. It makes sure that the given path to a testspec is
translated so common_test will pick the spec from the _build
directory, and not from the source tree.
|
| |
|
|
|
|
| |
This is necessary in order to automatically get the testspec included
as an artifact (i.e. copied to the _build dir) in the case when it is
stored in another directory than 'test'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: option 'spec' is not specifically handled when merging options
from the command line with options from rebar.config. Due to this, if
the config specifies a 'spec', then this will take precedence over any
'dir' and/or 'suite' on the command line.
This commit takes special care of all options that can be used to
select tests - meaning that if any of the options 'spec', 'dir',
'suite', 'group' or 'case' are specified on the command line, then all
'spec', 'dir', 'suite', 'group' and 'case' options in rebar.config
will be ignored.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
