| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
|
| |\ \ \
| |/ /
|/| | |
upgrade relx 3.31.0
|
| |/ / |
|
| |\ \
| | |
| | | |
Update certifi, ssl_verify_fun, bbmustache
|
| |/ / |
|
| |\ \
| | |
| | | |
upgrade relx to 3.30.0
|
| |/ / |
|
| |\ \
| | |
| | | |
support dialyzer plt location and prefix in cli args
|
| |/ / |
|
| |\ \
| | |
| | | |
rebar3 eunit: Hide slowest tests profile output by default
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Enable parallel build
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch does two things:
1. it broadens the interface for the compiler module so that
non-first-file modules can possibly be parallelized. This is done by
dynamically switching on `[ListOfFiles]`, which remains sequential as
before, or `{[SeqPriority], [Parallel]}`, which divides regular files
between higher priority ones and those that can be in parallel
2. implements this mechanism in the rebar compiler, based on the erl
file digraph. If a file has an in-neighbour, it is depended on by
another file. The mechanism therefore makes it so all files that have
dependants get compiled in their strict relative sequential order
first, and then the undepended-on files get compiled together in
parallel.
By running:
./rebar3 ct --suite test/rebar_compile_SUITE.erl --case \
recompile_when_parse_transform_inline_changes --repeat 50
the previous iteration of this would rapidly fail, and this one succeeds
every time.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Support for parallel compilation of *.erl file was dropped before 3.0 release.
However, our tests for a project containing ~500 source files show substantial gain, lowering compilation time from 58 seconds to 18 on a MacBook Pro 15" (4 cores, 8 threads), and to just 10 seconds on Xeon-D machine.
|
| |\ \ \ \
| | | | |
| | | | | |
Catch errors in writing the package cache
|
| |/ / / / |
|
| |\ \ \ \
| |_|/ /
|/| | | |
Fix rebar3 deps command
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Deps command shows an * if the local state of the dependencies do not
match the config file, highlighting the differences between the lock
file and the config file if there are any.
|
| | |/ /
| | |
| | |
| | |
| | | |
deps command was printing an * even when deps were updated, this commit
makes it call rebar_fetch:needs_update/2 for each of them
|
| |\ \ \
| |/ /
|/| | |
Attempt at support sys_config_src in shell
|
| |/ / |
|
| |\ \
| |/
|/| |
Fix provider hook handling for escriptize
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Previously all escriptize hooks from all apps in the project were
executed, which could lead to issue in case of dependencies on artifacts
which are created by these hooks.
Now the behaviour is similar to the handling of other non-global hooks.
|
| |\
| |
| | |
Remove ignored hex_core artifact from repo
|
| |/ |
|
| |\
| |
| | |
Fix handling of transient locks during upgrade
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have a problem in the handling of locks in the `upgrade
<app>` command when a transitive dependency switches supervision trees.
If we start with:
A
/ \
B1 C
|
D
|
E
And upgrade to:
A
/ \
B2 C
| |
E D
by calling `rebar3 upgrade b`, we would expect the ugprade command to do
so directly. However we are currently left with the following lock file:
A
/ \
B2 C
|
D
|
E
This is _not_ critical since on the next run, the lock file is fixed
automatically through an install-deps sequence. However, this is a
jarring state in which to leave a project.
The reason is that we proceed the following way to handle an upgrade:
1. pick the name of the chosen app, and unlock it if it's at the level 0
2. grab a list of all its current children (and their own) and unlock
them
3. do the same for all the other unlocked dependencies
4. pass this new lock internal format to the get-deps provider in
upgrade mode
5. take the result and save it to the lock file.
What's interesting is that right now this yields invalid locks at
step 3, because we have removed the lock on B1, but not on E
(which we don't yet know is going to be a new child of the next
B version until we fetch it)
In step 4, we fetch dependencies, and in there we compare the
pre-upgrade locks and fetch structure with those expected in the current
lock state, and rebuild everything.
The fix in this commit adds a check there where if the app is in the
current lock set at a level deeper than the current one, the lock is
forced to be refreshed as if it were not there. This lock would get
refreshed on a blank run anyway since the current lock set would start
empty (rather than pre-populated by `upgrade`), and the level-order
traversal ensures that the locks remain safe in all cases.
Fixes #2030
|
| | |
|
| | |
|
| |\
| |
| | |
upgrade relx 3.29.0
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- vendor in hex_core at v0.5.0
- Change where repo_name should be the org and not the parent
- Changed rebar_utils:url_append_path/2 to not explicitly add a '?',
this is returned in the Query chunk by http_uri:parse/1 (e.g., "?foo=bar")
- update organization_merging test to expect the sub-repo as the repo_name
- Add tests for rebar_utils:url_append_path/2
- Stop referencing/setting "organization" in config and use new
organization settings (api_repository and repo_organization)
- Do not set (assume) the read key is valid for any/every repo
- Set repo_organization and api_repository to org
- Update tests to check for new config opts
|
| |\
| |
| | |
Abort when file:consult/1 returns an error in rebar3_hex_repos:auth_config/1
|
| |/
|
|
|
|
| |
- Modified rebar_hex_repos:auth_config/1 to abort on error except in
the case of enoent, in which we return an empty map.
- added auth_config_errors test to test/rebar_pkg_repos_SUITE
|
| |\
| |
| | |
switch documentation links to https where supported
|
| |/ |
|
| |\
| |
| | |
Include version in plugin list
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| | |
Bump cth_readable
|
| |/
|
|
|
| |
Handles some internal changes in logger in OTP-21.2 that broke the
follow-up error printouts after the first failure of a CT run
|
| |\
| |
| | |
Support setting shell hot code loading blacklists
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by default, all apps except internal rebar3 ones can be blacklisted.
Some months ago, someone added support for configurable lists within
rebar3 itself using the .app env.
This PR re-exports that functionality from the rebar.config file, so
that one can set something like:
{shell, [
{app_reload_blacklist, [cowboy, ranch]}
]}.
Which will allow to prevent applications that often crash when being
reloaded from doing so. For example, cowboy and ranch processes can be
stuck in an accept call for multiple reloads in dev, which ends up
causing large failures.
|
| |\
| |
| | |
Add --relvsn and --relname to rebar3 shell
|
| | |
| |
| |
| |
| |
| |
| | |
Allows to select one of many releases conditionally.
Default behaviour should be unchanged from existing one.
Can filter on only the version or only the name, or both.
|
| |\ \
| | |
| | | |
Fix handling of updated files in extra_src_dirs
|
